JavaScript GCP KMS Storage CI: make publish workflow test the shipped tree and gate on an unpublished version (KSM-1530)

[stas-schaller]

Summary

JavaScript GCP KMS Storage CI: the publish workflow's test job now installs from the exact curated lockfile, and the workflow now gates on the target version being unpublished before doing any SBOM or approval work.

Changes

Maintenance

• build-npm (the job that runs npm test) used npm install while generate-sbom and publish-npm both used npm ci. npm install can resolve inside each declared range and can rewrite package-lock.json mid-job, so the tests gating the release weren't guaranteed to run against the same tree the SBOM describes or that ultimately publishes. Switched to npm ci. (KSM-1530)
• Ported core's get-version/validate-version job pattern from publish.npm.yml: get-version extracts the version from package.json, validate-version checks registry.npmjs.org for that version and aborts on a 200 (already published) or anything other than a clean 404. generate-sbom and publish-npm now both depend on validate-version. Package name in the registry check is @keeper-security%2Fsecrets-manager-gcp (URL-encoded), verified against this package's own name rather than copy-pasted from core's.

Testing

Validated via /gha-check: actionlint clean; act -l confirms the job graph runs get-version → validate-version → generate-sbom → build-npm → publish-npm in that order. zizmor's one low-severity finding (npm install -g npm@latest in publish-npm, ad-hoc package install) is pre-existing on this file and matches the same pattern in core's own publish.npm.yml — not introduced by this change.

The actual OIDC token exchange and live npm registry check can only be exercised by a real workflow_dispatch run, not locally.

Breaking Changes

None.

Related Issues

• Jira: KSM-1530

[mgallego-keeper]

Summary

This PR changes build-npm's install step from npm install to npm ci in .github/workflows/publish.npm.storage.gcp.kms.yml. It also adds get-version and validate-version jobs, ported from core's publish.npm.yml, and gates generate-sbom and publish-npm on validate-version.

Verification

I read the resulting job graph: get-version, then validate-version, then generate-sbom and build-npm in parallel, then publish-npm. This gates the SBOM upload and the prod environment approval behind the version check. A repeated or mistaken dispatch now aborts early, before either of those runs.

The registry check uses @keeper-security%2Fsecrets-manager-gcp as the package name. That is this package's own name, correctly encoded, not copied from core's workflow.

I ran actionlint against the new workflow file. It is clean.

I ran zizmor against the new workflow file. It reports one low-severity finding: an ad-hoc npm install -g npm@latest step. I checked the same tool against the workflow before this PR. The same finding is present there too, at the equivalent line. It is pre-existing, not introduced by this PR.

I merged this PR onto the release branch tip and ran npm ci and the full test suite. All 124 tests pass.

Merge order

See the note on #1189 for the overlap and merge order across #1196 to #1200. This PR and #1200 both add a line to CHANGELOG.md at the same point in the file. That produces a real merge conflict, confirmed by testing it directly. The fix is a one-line manual resolution: keep both new lines.