Chore/update ci actions

[akberc]

Important

Update CI workflow to use latest GitHub Actions and switch to GitHub Packages; downgrade zod dependency.

• CI Workflow:
  • Update actions/checkout to v6 and actions/setup-node to v6 in .github/workflows/ci.yml.
  • Change npm registry URL to https://npm.pkg.github.com for publishing.
  • Remove version check step and publish directly to GitHub Packages using NODE_AUTH_TOKEN.
• Dependencies:
  • Downgrade zod from ^4.2.1 to ^3.22.0 in examples/gmail-viewer/package.json.

^{This description was created by for 417c0ef. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to 417c0ef in 2 minutes and 16 seconds. Click for details.

• Reviewed 125 lines of code in 6 files
• Skipped 1 files when reviewing.
• Skipped posting 3 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. .github/workflows/ci.yml:61

• Draft comment:
  Verify removal of the version-check step – publishing now happens unconditionally which could trigger duplicate publish errors if the version isn’t bumped.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

2. .github/workflows/ci.yml:52

• Draft comment:
  Ensure the registry URL change to GitHub Packages is paired with using a properly scoped package name; GitHub Packages typically require scoped names.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The comment starts with "Ensure", which is explicitly mentioned in the rules as a red flag ("If the comments starts with 'Verify that...' or 'Ensure that...', it is likely not useful"). The comment is asking the author to verify/ensure something rather than pointing out a definite problem. Additionally, from the removed code in the diff, I can see the package was already scoped as '@dyanet/imap', so the package likely already has a scoped name. The comment doesn't provide strong evidence of an actual problem - it's speculative and asks for confirmation rather than identifying a concrete issue. I might be missing context about whether the package.json file actually has the correct scoped name configured. The comment could be valid if the package name in package.json is not properly scoped, but I can't see that file in the diff. Even if the package.json might not have the correct scoped name, the comment violates the rule about not asking for verification/confirmation. The comment should either point out a definite issue with evidence, or not be made at all. Since I can't see package.json in this diff, and the comment is phrased as "ensure" rather than "this is wrong", it should be deleted. This comment should be deleted because it starts with "Ensure", which is asking for verification rather than pointing out a concrete issue. The rules explicitly state not to make comments that ask the author to confirm, verify, or ensure things. Without seeing the package.json file in this diff, there's no strong evidence of an actual problem.

3. examples/gmail-viewer/package.json:28

• Draft comment:
  Confirm that downgrading zod from ^4.2.1 to ^3.22.0 is intentional, as this may break compatibility if APIs from v4 are used.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% This comment violates several rules: 1) It asks the PR author to confirm their intention ("Confirm that..."), which is explicitly mentioned as something NOT to do in the rules. 2) It's speculative ("may break compatibility if APIs from v4 are used") - it doesn't definitively identify a problem. 3) The rules explicitly state "Do NOT comment on dependency changes, library versions that you don't recognize, or anything else related to dependencies." This is clearly a dependency version change. The comment doesn't provide actionable feedback - it just asks for confirmation. Could this be a legitimate concern if there's actual evidence in the codebase that v4 APIs are being used? Perhaps the automated tool detected usage of v4-specific features that would break with this downgrade? Even if there were v4-specific APIs being used, the build process would catch those errors (type checking, runtime errors, etc.), which falls under "anything that would be obviously caught by the build." The comment doesn't point to specific code that uses v4 features - it's purely speculative. Without concrete evidence of v4 API usage in the diff or comment, this is just asking for confirmation on a dependency change. This comment should be deleted. It violates multiple rules: it asks the author to confirm their intention, it's about a dependency change (which the rules say to ignore), and it's speculative rather than identifying a definite issue. Any actual compatibility issues would be caught by the build process.

Workflow ID: wflow_1xxBMcAf3jUGOjKm

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}