ci: fix labeled-PR release path so npm publish actually fires

[baransu]

Summary

Two bugs in the publish chain caused PR #12 (the release-trigger for 0.6.4) to bump package.json, tag, and create the GitHub Release — but silently skip the npm publish step.

Bug 1: npm-publish.yml gated on event_name == 'workflow_call'

When a reusable workflow is invoked via workflow_call, github.event_name reflects the root triggering event of the caller (in our case pull_request), not the literal string 'workflow_call'. The condition never matched, the build job was marked skipped, and npm publish never ran. Replaced with event_name != 'release' — trust the caller's own gating when called as a sub-workflow; only re-check draft / tag-prefix when fired directly by a release event.

Bug 2: actions/create-release@v1 used default GITHUB_TOKEN

Per GitHub's security model, events emitted by GITHUB_TOKEN do not trigger downstream workflows. So even if someone created a release expecting the release: [published] event to fire npm-publish.yml, nothing happened. Swapped to the app token already configured earlier in the same job (steps.app-token.outputs.token), restoring the release path as a viable backup trigger.

Recovery plan for 0.6.4

package.json is at 0.6.4 on master, tag v0.6.4 exists, GitHub Release v0.6.4 exists — but npm registry is still at 0.6.3. After this PR merges, recreate the v0.6.4 GitHub Release from a human/app token (e.g. gh release delete v0.6.4 --cleanup-tag=false && gh release create v0.6.4 --target master --title v0.6.4 --notes "..."). The new release: [published] event will fire npm-publish.yml, which now passes the if and publishes 0.6.4 to npm. The tag stays the same, so no version churn.

Test plan

• actionlint / yaml syntactically valid
• Merge → manually recreate v0.6.4 release → confirm Publish to NPM run completes → npm view @jam.dev/rimless version returns 0.6.4
• Future labeled-PR releases publish without manual intervention

[devin-ai-integration]

Devin Review found 1 potential issue.

View 2 additional findings in Devin Review.

[devin-ai-integration]

🟡 App token on release creation causes duplicate npm publish (one will always fail)

Switching to the app token for actions/create-release (line 81) means the resulting release: [published] event will now trigger other workflows (unlike GITHUB_TOKEN, which suppresses such triggers). Since npm-publish.yml is triggered by both release: [published] (line 4-5 of that file) and workflow_call (from the publish-package job at .github/workflows/publish-release.yml:90-94), every automated release will now invoke npm publish twice concurrently: once via the release event and once via the workflow_call chain. One invocation will succeed; the other will fail with a 403 (version already exists on npm), producing a noisy, permanently-failed workflow run on every release.

The two trigger paths

1. publish-release job creates a GitHub Release with the app token → fires release: [published] → triggers npm-publish.yml directly.
2. publish-package job (needs: publish-release) → calls npm-publish.yml via workflow_call.

Both paths pass the updated if condition in npm-publish.yml and will execute npm publish.

Prompt for agents

The problem is that switching from GITHUB_TOKEN to the app token for the create-release step means the release: [published] event will now propagate and trigger npm-publish.yml directly, in addition to the existing workflow_call invocation from the publish-package job. This causes a duplicate npm publish.

There are several ways to fix this:

1. Keep the app token for create-release (to support manual re-cuts) but remove the publish-package job (lines 88-94 of publish-release.yml) entirely, relying solely on the release event to trigger npm-publish.yml.

2. Keep both paths but add a concurrency group to npm-publish.yml so only one run proceeds (e.g. concurrency: group: npm-publish-${{ github.ref }}, cancel-in-progress: true). However, this is fragile — the cancelled run still shows as failed.

3. Keep the GITHUB_TOKEN for create-release (reverting this change) and keep the workflow_call path as the sole publish mechanism. If manual re-cut support is needed, address it separately.

Option 1 is the cleanest: remove the redundant publish-package workflow_call job and let the release event (now properly propagated via the app token) be the single trigger for npm-publish.yml.

---

Was this helpful? React with 👍 or 👎 to provide feedback.