chore(release): publish to npm with trusted publishing by cs-raj · Pull Request #2741 · contentstack/cli · GitHub
Skip to content

chore(release): publish to npm with trusted publishing - #2741

Open
cs-raj wants to merge 3 commits into
developmentfrom
feat/DX-27614
Open

cs-raj wants to merge 3 commits into
developmentfrom
feat/DX-27614

Conversation

@cs-raj

@cs-raj cs-raj commented Oct 22, 2026 •

Copy link
Copy Markdown
Contributor

Problem

The three release-production-*.yml workflows publish the 5 cli packages to npm with a long-lived NPM_TOKEN on every push to main.

The SE1 publishing policy requires OIDC trusted publishing instead: no token, one release.yml that runs when a release is published, Node 24.

Every run since August also ends red: the post-publish gh release create step fails with HTTP 403.

Fix

The three workflows and .github/config/release.json are replaced by one release.yml.

Before After
Trigger push to main, manual run release: published
Files release-production-pipeline.yml calling …-platform-plugins.yml and …-core.yml release.yml (npm checks the calling workflow's filename)
npm auth NPM_TOKEN OIDC: id-token: write, no token
Publish 5 × JS-DevTools/npm-publish@v3 steps: utilities, command, config, auth, then core one step per package in the same order, each running npm publish --access public unless that version is already on npm
Node / npm 22.x / npm 10 24 / latest npm
Install clean:all, then pnpm install --no-frozen-lockfile pnpm install --frozen-lockfile
Checkout branch head, credentials persisted the release tag, persist-credentials: false
Actions checkout, setup-node, pnpm/action-setup @v4 checkout @v7, setup-node @v7, pnpm/action-setup pinned to its v6.1.0 commit
Removed json-to-variables + release.json (unused), corepack steps, gh release create (403) —
Unchanged ggshield install, GITGUARDIAN_API_KEY on the publish step —
.talismanrc — checksum exemption for release.yml: Talisman flags the pinned action SHA and the secrets. reference (false positives)

Deviations from the policy's sample workflow, all because this is a pnpm monorepo with 5 packages:

  1. pnpm/action-setup step: the repo uses pnpm.
  2. cache: 'pnpm' instead of 'npm': there is no package-lock.json.
  3. pnpm install --frozen-lockfile instead of npm ci: the same lockfile-strict install, for pnpm.
  4. Explicit pnpm -r --sort run build: when a release publishes only core, the skipped packages' prepack never runs, and core's build needs their lib/.
  5. One publish step per package, in the old workflows' order (utilities, command, config, auth, core), skipping versions already on npm: one release publishes only what was bumped, and a failed step names its package and stops the job.
  6. ggshield step with GITGUARDIAN_API_KEY: the GitGuardian scan on publish.
  7. Latest action majors instead of @v4 (v4 runs on Node 20, which is end-of-life); the third-party pnpm/action-setup is pinned to a commit SHA, as SRE recommended.

Verification

Node 22 and Node 24: frozen-lockfile install, build and unit tests pass (362 passing). The publish steps, run with npm publish stubbed, go in the old order, skip the 5 versions already on npm, pick up a bumped one, and a failed step stops the job.

Replace the three release-production workflows and release.json with one
release.yml that runs on release:published, so the npm trusted publisher
can be keyed on the filename. Drop NPM_TOKEN in favour of id-token: write
(OIDC), run on Node 24 with npm@latest (trusted publishing needs npm >=
11.5.1), install with a frozen lockfile and check out the release tag
without persisted credentials. Each package publishes in dependency order
and is skipped when its version is already on npm, so one release
publishes only what was bumped.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@cs-raj
cs-raj requested review from a team as code owners October 22, 2026 13:36
@cs-raj cs-raj self-assigned this Oct 22, 2026
@snyk-io

snyk-io Bot commented Oct 22, 2026 •

Copy link
Copy Markdown

✅ Snyk checks have passed. No issues have been found so far.

Status Scan Engine Critical High Medium Low Total (0)
✅ Open Source Security 0 0 0 0 0 issues
✅ Licenses 0 0 0 0 0 issues
✅ Code Security 0 0 0 0 0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

@github-actions

Copy link
Copy Markdown

🔒 Security Scan Results

ℹ️ Note: Only vulnerabilities with available fixes (upgrades or patches) are counted toward thresholds.

Check Type Count (with fixes) Without fixes Threshold Result
🔴 Critical Severity 0 0 10 ✅ Passed
🟠 High Severity 0 131 25 ✅ Passed
🟡 Medium Severity 1 232 500 ✅ Passed
🔵 Low Severity 0 0 1000 ✅ Passed

⏱️ SLA Breach Summary

⚠️ Warning: The following vulnerabilities have exceeded their SLA thresholds (days since publication).

Severity Breaches (with fixes) Breaches (no fixes) SLA Threshold (with/no fixes) Status
🔴 Critical 0 0 15 / 30 days ✅ Passed
🟠 High 0 0 30 / 120 days ✅ Passed
🟡 Medium 0 1 90 / 365 days ⚠️ Warning
🔵 Low 0 0 180 / 365 days ✅ Passed

ℹ️ Vulnerabilities Without Available Fixes (Informational Only)

The following vulnerabilities were detected but do not have fixes available (no upgrade or patch). These are excluded from failure thresholds:

  • Critical without fixes: 0
  • High without fixes: 131
  • Medium without fixes: 232
  • Low without fixes: 0

⚠️ BUILD PASSED WITH WARNINGS - SLA breaches detected for issues without available fixes

Consider reviewing these vulnerabilities when fixes become available.

cli-config and cli-auth do not depend on each other, so pnpm --sort was
free to publish auth before config. List the five packages explicitly in
the order the old release workflows used: utilities, command, config,
auth, then core. A failed publish still stops the step before the next
package.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown

🔒 Security Scan Results

ℹ️ Note: Only vulnerabilities with available fixes (upgrades or patches) are counted toward thresholds.

Check Type Count (with fixes) Without fixes Threshold Result
🔴 Critical Severity 0 0 10 ✅ Passed
🟠 High Severity 0 131 25 ✅ Passed
🟡 Medium Severity 1 232 500 ✅ Passed
🔵 Low Severity 0 0 1000 ✅ Passed

⏱️ SLA Breach Summary

⚠️ Warning: The following vulnerabilities have exceeded their SLA thresholds (days since publication).

Severity Breaches (with fixes) Breaches (no fixes) SLA Threshold (with/no fixes) Status
🔴 Critical 0 0 15 / 30 days ✅ Passed
🟠 High 0 0 30 / 120 days ✅ Passed
🟡 Medium 0 1 90 / 365 days ⚠️ Warning
🔵 Low 0 0 180 / 365 days ✅ Passed

ℹ️ Vulnerabilities Without Available Fixes (Informational Only)

The following vulnerabilities were detected but do not have fixes available (no upgrade or patch). These are excluded from failure thresholds:

  • Critical without fixes: 0
  • High without fixes: 131
  • Medium without fixes: 232
  • Low without fixes: 0

⚠️ BUILD PASSED WITH WARNINGS - SLA breaches detected for issues without available fixes

Consider reviewing these vulnerabilities when fixes become available.

Give each of the five packages its own publish step, as the old release
workflows did, so a failed publish names the package in the Actions run
and stops the job before the next one. The order is unchanged:
utilities, command, config, auth, core.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown

🔒 Security Scan Results

ℹ️ Note: Only vulnerabilities with available fixes (upgrades or patches) are counted toward thresholds.

Check Type Count (with fixes) Without fixes Threshold Result
🔴 Critical Severity 0 0 10 ✅ Passed
🟠 High Severity 0 131 25 ✅ Passed
🟡 Medium Severity 1 232 500 ✅ Passed
🔵 Low Severity 0 0 1000 ✅ Passed

⏱️ SLA Breach Summary

⚠️ Warning: The following vulnerabilities have exceeded their SLA thresholds (days since publication).

Severity Breaches (with fixes) Breaches (no fixes) SLA Threshold (with/no fixes) Status
🔴 Critical 0 0 15 / 30 days ✅ Passed
🟠 High 0 0 30 / 120 days ✅ Passed
🟡 Medium 0 1 90 / 365 days ⚠️ Warning
🔵 Low 0 0 180 / 365 days ✅ Passed

ℹ️ Vulnerabilities Without Available Fixes (Informational Only)

The following vulnerabilities were detected but do not have fixes available (no upgrade or patch). These are excluded from failure thresholds:

  • Critical without fixes: 0
  • High without fixes: 131
  • Medium without fixes: 232
  • Low without fixes: 0

⚠️ BUILD PASSED WITH WARNINGS - SLA breaches detected for issues without available fixes

Consider reviewing these vulnerabilities when fixes become available.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant