Skip to content

Releases: coroboros/ci

0.1.13

20 May 11:54
f174724

Choose a tag to compare

Documentation

  • README — add lockfile=true to the recommended NPM_CONFIG_FILE template. Pnpm < 11.0.0 interprets the preceding package-lock=false line as lockfile=false, disabling pnpm-lock.yaml reads and breaking pnpm install --frozen-lockfile in javascript/base. The new line re-enables pnpm's lockfile explicitly on pnpm 10.x and is harmless on pnpm >= 11, where lockfile=true is already the default and package-lock is scoped to npm's lockfile only.

0.1.12

20 May 07:31
04df339

Choose a tag to compare

Documentation

  • README — document the recommended hardened NPM_CONFIG_FILE .npmrc (per-line rationale) and the token bootstrap auth setup (NPM_PACKAGE_REGISTRY_TOKEN + NPM_EXTRA_CONFIG secrets, why npm publish is used on that path, migration token → OIDC after first publish). Reaffirms that every npm-publish-related value is a secret (encrypted), not a GitHub var. Reflects the v0.1.11 token-path hardening.

0.1.11

20 May 07:29
f9cfa5d

Choose a tag to compare

Fixes

  • javascript-npm-packages — pass --ignore-scripts --access public to npm publish on the token bootstrap path. Defense in depth against postinstall-worm supply-chain attacks: install-time scripts are already skipped by pnpm install --frozen-lockfile --ignore-scripts in javascript/base; the publish flag now also skips prepack/postpack/publish/postpublish while the long-lived bootstrap token is in env. prepublishOnly still runs (known npm publish behavior — the flag does not cover it), but it invokes our own gates from the frozen lockfile that already ran in the base action. The bootstrap token's exposure narrows to one publish — switch to OIDC + provenance via Trusted Publisher for 1.0.1+ to eliminate the long-lived token entirely.

0.1.10

20 May 06:47
2e8b919

Choose a tag to compare

Fixes

  • javascript-npm-packages — use npm publish for the token bootstrap path. v0.1.5 → v0.1.9 chased pnpm-side workarounds (env vars, configs, npx version pin, standalone binary download with SHA verify, manage-package-manager-versions=false) and each one hit a different pnpm 10/11 dead-end: pnpm 11 auto-attempts OIDC without .npmrc fallback; pnpm 10.33.0 via npx is intercepted by corepack; the standalone 10.33.0 binary self-switches on packageManager: pnpm@11.x and crashes against its own snapshot. npm publish is not managed by corepack, does not auto-attempt OIDC, reads _authToken from .npmrc directly, and produces an identical tarball (same files, same prepublishOnly). The OIDC branch (pnpm publish --provenance --no-git-checks) is unchanged — pnpm OIDC works once a Trusted Publisher is bound; only the pre-Trusted-Publisher bootstrap takes the npm CLI path. Revert to a single pnpm publish once pnpm 11.x's bootstrap-via-token regression is upstream-fixed.

0.1.9

20 May 06:42
1011437

Choose a tag to compare

Fixes

  • javascript-npm-packages — pass --config.manage-package-manager-versions=false to the pinned pnpm 10.33.0 binary so it does not attempt to self-switch to the consumer's packageManager pin. v0.1.8 successfully fetched and SHA-verified pnpm-linux-x64@10.33.0, but pnpm 10.33.0 read packageManager: pnpm@11.x from the package's package.json and tried pnpm add @pnpm/exe@11.x, which crashes against the single-file standalone binary (/snapshot/dist/pnpm.cjs not found). Disabling the self-switch keeps the pinned 10.33.0 running for the publish call only.

0.1.8

20 May 06:39
b4aa5f7

Choose a tag to compare

Fixes

  • javascript-npm-packages — fetch the pnpm 10.33.0 standalone binary directly for the token publish path. v0.1.7's npx -y pnpm@10.33.0 publish was intercepted by corepack — every pnpm invocation in a project with a packageManager field goes through the corepack shim, including the binary that npx resolves to, so the consumer's pnpm@11.x ran anyway and the same ERR_PNPM_AUTH_TOKEN_EXCHANGE 404 surfaced. The fix downloads pnpm-linux-x64 from the pinned v10.33.0 GitHub release into ${RUNNER_TEMP}, verifies its SHA-256 (8d4e8f7d778e8ac482022e2577011706a872542f6f6f233e795a4d9f978ea8b5), and executes it by absolute path. Bypasses corepack entirely; the consumer package's own packageManager pin is untouched. The OIDC branch (pnpm publish --provenance --no-git-checks) is unchanged. Revert to a single pnpm version once pnpm 11.x's bootstrap-via-token regression is upstream-fixed.

0.1.7

20 May 06:34
0852430

Choose a tag to compare

Fixes

  • javascript-npm-packages — invoke pnpm 10.33.0 via npx for the token publish path only. v0.1.5 (env -u) and v0.1.6 (NPM_CONFIG_PROVENANCE=false) both failed to stop pnpm >= 11.1.3 from attempting OIDC in CI; after OIDC fails (no Trusted Publisher on a bootstrap publish), pnpm 11.x does not fall back to the .npmrc _authToken and the PUT 404s. pnpm 10.33.0 has no OIDC code path, reads _authToken from .npmrc directly, and publishes. Using npx pnpm@10.33.0 keeps the consumer package's own packageManager pin (typically pnpm@11.x) intact — corepack still drives every other step (install, lint, build, test, the OIDC branch); only the token-path pnpm publish call uses 10.33.0. The OIDC branch (pnpm publish --provenance --no-git-checks) is unchanged. Revert to a single pnpm version once the pnpm 11.x bootstrap-via-token regression is upstream-fixed.

0.1.6

20 May 06:26
0c1de47

Choose a tag to compare

Fixes

  • javascript-npm-packages — disable provenance auto-detection on the token publish path. v0.1.5's env -u of the GitHub OIDC env vars caused pnpm >= 11.1.3 to emit ERR_PNPM_ID_TOKEN_GITHUB_WORKFLOW_INCORRECT_PERMISSIONS and still fail the PUT with 404 — pnpm in CI auto-enables provenance=true regardless of the OIDC env vars, and skipping OIDC after the auto-enable leaves the publish without usable auth. Set NPM_CONFIG_PROVENANCE=false on the token-path command instead: pnpm sees provenance explicitly disabled, never attempts OIDC, and reads _authToken from .npmrc directly. The OIDC branch is unchanged. Workflow stays pnpm-version-agnostic.

0.1.5

20 May 06:20
2ce9a70

Choose a tag to compare

Fixes

  • javascript-npm-packages — isolate the token publish path from pnpm 11's auto-OIDC. pnpm >= 11.1.3 auto-attempts the OIDC token exchange whenever ACTIONS_ID_TOKEN_REQUEST_URL / ACTIONS_ID_TOKEN_REQUEST_TOKEN are present (GitHub sets them when id-token: write is granted at the job level — required for the post-bootstrap OIDC branch). On the token bootstrap path (a new scoped package without a Trusted Publisher binding, or any token-locked exception), the auto-attempt resolves to 404 from npm and pnpm then publishes with no usable auth — the PUT fails with 404. The fix env -u's both vars on the token-path command only — the OIDC branch is unchanged. Keeps the workflow pnpm-version-agnostic: both 10.x and 11.x work on the token path, and 11.x (>= 11.0.7) still drives OIDC when the token is absent.

0.1.4

15 May 11:06
9fb254a

Choose a tag to compare

Fixes

  • javascript-npm-packages — read NPM_EXTRA_CONFIG from secrets, not vars. It is appended verbatim into .npmrc, so it can carry auth material; a variable would expose that in plaintext and in logs. Declared as an optional workflow_call secret; callers forward it via their secrets: block.