Fix: Auto-publish on release-PR merge (@W-23235833@)

[joeluong-sfcc]

Summary

• Same fix the isomorphic SDK just landed in PR Add CCDC object ids of inventory and slas admin apis #293 (W-23235820): both release-on-merge.yml and publish.yml fire off the same pull_request: closed event on a merged release/v* branch, both authenticate with GITHUB_TOKEN, and run in parallel. Neither depends on a downstream event from the other.
• Previous shape had publish.yml on release: published — bit us because GitHub blocks workflow chains authored by GITHUB_TOKEN, so the release fired but no runner observed it. v6.4.0 would have hit the same wall on merge.
• workflow_dispatch stays on publish.yml as a manual fallback that takes an existing tag and re-publishes that ref.
• publish.yml now runs the same tri-source version cross-check (branch/tag ↔ package.json ↔ CHANGELOG.md) that release-on-merge.yml does, so a version-mismatched merge can't ship npm without a matching tag.

Test plan

• npm run test:workflow — 21/21 pass (14 existing + 7 new). New suite src/test/publishAutoTriggerWorkflow.mjs locks the trigger surface (regex-on-YAML): pull_request: closed on main, merged==true && same-repo && startsWith(head.ref, 'release/v') gate, merge_commit_sha checkout ref, absence of release: published, required workflow_dispatch tag input, that release-on-merge never reintroduces a PAT, and the new tri-source cross-check (step presence, PR-path regex, dispatch-path regex, package.json read, CHANGELOG awk read, exit 1 on mismatch).
• Sensitivity-checked each assertion by reverting the surface it locks and confirming the matching test goes red before restoring.
• actionlint .github/workflows/publish.yml .github/workflows/release-on-merge.yml — clean.
• npm run lint — clean.

Verification

What the local checks cover

• The YAML surface: trigger, if-condition, checkout ref, workflow_dispatch input, the GITHUB_TOKEN / no-PAT invariant on release-on-merge, and the tri-source version cross-check on publish.yml. Locked in CI via test:workflow.

What it does NOT cover

• The workflow-runtime plumbing: does GitHub actually fire publish.yml on pull_request: closed given this if: gate, does the runner resolve merge_commit_sha to a checkoutable commit, do release-on-merge and publish.yml both fire on the same merge event. Not observable from a branch — we can't fake a merged PR without merging one, and this repo's release trigger doesn't fire on branch pushes.

Plan to close the remaining gaps

• First real closure is v6.4.0's merge (release PR Release v6.4.0 for ECOM v26.7 (@W-23232606@) #452, W-23232606). Expected: both workflows fire in parallel from the same pull_request: closed event; both pass the tri-source cross-check; release-on-merge tags + creates the release with GITHUB_TOKEN; publish.yml checks out the merge commit and npm publish succeeds. If publish.yml doesn't fire, the workflow_dispatch fallback unblocks: run it with tag: v6.4.0 and it checks out the tag release-on-merge created.

Follow-ups

• Ticket's original AC-3 ("Workflow uses a non-GITHUB_TOKEN credential to create the release.") is superseded by this pivot. The pivot's premise is that no downstream release: published event is needed, so the release can stay GITHUB_TOKEN-authored. Iso ate this same AC change at PR Add CCDC object ids of inventory and slas admin apis #293 for the same reason (org-policy pushback on fine-grained PATs scoped to SalesforceCommerceCloud).

Future considerations

Findings from a second-pass code review — surfaced here for visibility, may be revisited in a future hardening pass. No follow-up tickets filed; no guarantee they'll be picked up.

• Loose branch-name gate. startsWith(head.ref, 'release/v') accepts release/v-foo, release/vBAD, release/v-hotfix. release-on-merge catches these downstream via ^release/v([0-9]+\.[0-9]+\.[0-9]+)$ — publish.yml's job-level gate has no such backstop, though the new tri-source cross-check inside the job now rejects them at step 3 anyway. Defense-in-depth gap at the gate level.
• No idempotency guard. Re-running the workflow after a successful publish 403s on npm (cannot publish over previously published versions). Red X on a release PR that already succeeded, false alarm. release-on-merge handles this pattern with a tag-exists / release-exists check; publish.yml could add a npm view <version> guard before publish.
• No concurrency: group. Two rapid release-PR merges (or a workflow_dispatch overlapping a merge-triggered run) race on npm publish. Not corrupting — npm 409s on duplicate versions and it's recoverable — but a real ceremony cost. concurrency: { group: publish, cancel-in-progress: false } serializes. Same trade-off iso PR Add CCDC object ids of inventory and slas admin apis #293 explicitly accepted.
• No timeout-minutes. A hung npm publish (registry outage) pins the runner for GitHub's 360-minute default. timeout-minutes: 15 fails fast.
• merge_commit_sha on squash/rebase-merged PRs is the synthetic "test-merge" candidate, not the SHA that lands on main. Inherited from release-on-merge — this diff perpetuates it. git checkout v6.5.0 would land on a detached HEAD diverging from main's linear history. Cleanup would touch release-on-merge too.
• Lock-test regex brittleness. Tests hard-code whitespace, key order, and the if: | block-scalar form. A benign yamlfmt/prettier reformat could red the CI without changing YAML semantics. Also, the release: published anti-regex misses quoted / spaced / block-list evasions (types: ['published'], types:\n - published, flow-syntax) — a future revert of the pivot could pass CI. A YAML-parsing approach (assert on the parsed structure) would be robust to both.
• .mjs excluded from eslint. lint:dev runs eslint . --ext .ts. The new lock-test file has no lint coverage — a missing header or unused import would go undetected. Sibling releaseOnMergeWorkflow.mjs has the same gap.

Out of scope

• Migrating to a GitHub App-based token (peter-evans/create-github-app-token). Mooted by the pivot — no PAT means no App-replacement need.
• Trusted Publishing (OIDC) on npm — tracked separately as W-22028201.
• Bumping actions/checkout@v3 in test.yml. Separate concern, keeps this diff focused.

Ticket

W-23235833

[vmarta]

Approving — design is sound and honestly documented. Verified the dropped npm run build is safe: prepack: npm run build runs on npm publish, so the build still happens.

nit (would be nice to fold into this PR if it's little work): the version cross-check gap you flagged as future-consideration 1 is the one finding that's unrecoverable rather than just a ceremony cost. release-on-merge.yml runs the tri-source guard (branch ↔ package.json ↔ CHANGELOG); publish.yml fires in parallel with none. A version-mismatch merge aborts release-on-merge (no tag, no release) but still ships the npm publish — and npm unpublish is time-limited, so the "tag exists iff published" invariant breaks with no undo.

Everything else on your future-considerations list (loose branch gate, raw dispatch tag, no idempotency guard, no concurrency, no timeout-minutes) is recoverable via npm's 409/403 and fine to defer. This one's cheap-ish (re-run the same branch↔package.json compare, or an npm view <version> guard before publish) and closes the only data-loss path — worth pulling in now if it's low-effort. Not a blocker either way.

[joeluong-sfcc]

Good callout, folded the tri-source cross-check into publish.yml — same shape as release-on-merge.yml (branch/tag ↔ package.json ↔ CHANGELOG.md, fail-loud on mismatch). Two source paths (PR head.ref, workflow_dispatch tag input) both land in the same downstream comparison; error labels differ per arm so the two workflow logs are easy to correlate on a mismatched merge.

Lock test #6 covers step presence, both regex arms, package.json read, CHANGELOG awk read, and the exit 1. Each assertion sensitivity-verified red-on-revert, green-on-restore. Full suite is 21/21.

Rest of the future-considerations list (loose gate, idempotency, concurrency, timeout, squash SHA, lock-test brittleness, .mjs lint gap) still deferred as you called out.