Add provenance to published package

[flevi29]

Pull Request

What does this PR do?

• https://docs.npmjs.com/generating-provenance-statements
• https://github.blog/security/supply-chain-security/introducing-npm-package-provenance/

Summary by CodeRabbit

• Chores
  • Updated release publishing to include provenance attestations and publish packages publicly for both latest and beta tags.
  • Adjusted CI workflow permissions to support the publishing process.
  • Minor formatting cleanup in environment variable configuration.
  • No changes to product functionality; this affects the release pipeline only.
  • End users will continue installing packages as before.

[coderabbitai]

Walkthrough

Updates the GitHub Actions publish workflow by adding explicit permissions, modifying npm publish commands to include provenance and public access for both latest and beta tags, and making a minor env formatting tweak.

Changes

Cohort / File(s)	Summary
CI workflow: npm publish adjustments \.github/workflows/publish.yml	Added job permissions (contents: read, id-token: write). Updated publish steps to npm publish --provenance --access public for latest and --tag beta for beta. Minor spacing tweak for NODE_AUTH_TOKEN env line.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  actor Dev as Developer
  participant GH as GitHub
  participant R as Actions Runner
  participant OIDC as GitHub OIDC
  participant NPM as npm Registry

  Dev->>GH: Push/tag triggering publish workflow
  GH-->>R: Start job (permissions: contents:read, id-token:write)

  Note over R,OIDC: Prepare for publish with provenance
  R->>OIDC: Request OIDC token (id-token: write)
  OIDC-->>R: OIDC token (JWT)

  R->>NPM: npm publish --provenance --access public
  alt Beta tag
    R->>NPM: npm publish --provenance --access public --tag beta
  end

  NPM-->>R: Publish result
  R-->>GH: Job status

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

I thump my paws on pipelines bright,
Tags hop “latest,” “beta” in flight—
With provenance packed in every cart,
Tokens signed before we start.
Public carrots on the registry shelf,
One small YAML, quite proud of itself. 🥕✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The title succinctly and accurately conveys the primary change—adding provenance information to the published package—and aligns with the content of the changeset without extraneous detail.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

✨ Finishing touches

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment

Tip

👮 Agentic pre-merge checks are now available in preview!

Pro plan users can now enable pre-merge checks in their settings to enforce checklists before merging PRs.

• Built-in checks – Quickly apply ready-made checks to enforce title conventions, require pull request descriptions that follow templates, validate linked issues for compliance, and more.
• Custom agentic checks – Define your own rules using CodeRabbit’s advanced agentic capabilities to enforce organization-specific policies and workflows. For example, you can instruct CodeRabbit’s agent to verify that API documentation is updated whenever API schema files are modified in a PR. Note: Upto 5 custom checks are currently allowed during the preview period. Pricing for this feature will be announced in a few weeks.

Please see the documentation for more information.

Example:

reviews:
  pre_merge_checks:
    custom_checks:
      - name: "Undocumented Breaking Changes"
        mode: "warning"
        instructions: |
          Pass/fail criteria: All breaking changes to public APIs, CLI flags, environment variables, configuration keys, database schemas, or HTTP/GraphQL endpoints must be documented in the "Breaking Change" section of the PR description and in CHANGELOG.md. Exclude purely internal or private changes (e.g., code not exported from package entry points or explicitly marked as internal).

Please share your feedback with us on this Discord post.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.83%. Comparing base (4f7c885) to head (ed93b21).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2039   +/-   ##
=======================================
  Coverage   98.83%   98.83%           
=======================================
  Files          18       18           
  Lines        1549     1549           
  Branches      334      334           
=======================================
  Hits         1531     1531           
  Misses         18       18           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (3)

.github/workflows/publish.yml (3)

32-32: Provenance flags: good; add a quick version guard to prevent surprise failures.

Node 22 ships with a modern npm that supports --provenance, but adding a tiny preflight step helps future maintainers:

• Add a step before publish: npm --version && node --version
• Optionally enforce minimum npm: npm -v | awk -F. '{exit !($1>=9)}' with a friendly message.

No functional change; improves diagnosability.

---

36-39: Mirror the condition style for prerelease branch.

Same note as above: prefer if: ${{ github.event.release.prerelease }} for consistency and readability.

---

31-34: Use expression syntax for step conditions
Convert string-quoted if: values to expression syntax in .github/workflows/publish.yml:

• Line 31: if: '!github.event.release.prerelease' → if: ${{ !github.event.release.prerelease }}
• Line 36: if: 'github.event.release.prerelease' → if: ${{ github.event.release.prerelease }}
  Optional: add explicit “.” in your npm publish commands (e.g. npm publish . --provenance --access public).

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 4f7c885 and ed93b21.

📒 Files selected for processing (1)

• .github/workflows/publish.yml (2 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: integration-tests (Node.js 22)
• GitHub Check: integration-tests (Node.js 20)

🔇 Additional comments (2)

.github/workflows/publish.yml (2)

12-14: Correct OIDC permissions for npm provenance.

Adding permissions: { contents: read, id-token: write } at the job level is exactly what npm provenance requires. LGTM.

---

34-34: Ensure NPM_TOKEN is an automation token with publish scope.

For CI publishing (with provenance) npm recommends an Automation token scoped to the package/org. Please confirm secrets.NPM_TOKEN is:

• Token type: Automation
• Permissions: Can publish both stable and beta
• Rotated per org policy

Also applies to: 39-39