ci: fix release-preview-publish.yml action#7723
Conversation
Currently, `npm publish` runs `pnpm docs:verify-version`, which might possible fail if there are any `<MERMAID_RELEASE_VERSION>` placeholders in our docs. I've made a new environment variable, `ONLY_WARN_ON_VERIFY_ERROR`, that can be used to disable this behaviour, allowing us to publish release previews.
If we don't have the `id-token: write` permission, there's no way we can accidentally write the NPM! But we still need `packages: write` to write to GitHub Packages.
Make sure that we use a preview tag for previews
Right now, since we're using `npm publish` instead of `pnpm publish`, the `^workspace:` specifier in our `package.json` file won't work. We're also not publishing a `@mermaid-js/parser` package. Instead, we can use `pnpm pack` to create a `.tgz` that `npm publish` can upload. We can also use `bundledDependencies` to include the `@mermaid-js/parser` package, in case the latest preview version of mermaid requires new changes to that package.
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## release/11.15.0 #7723 +/- ##
==================================================
+ Coverage 3.33% 3.35% +0.01%
==================================================
Files 542 541 -1
Lines 56881 56879 -2
Branches 839 842 +3
==================================================
+ Hits 1899 1906 +7
+ Misses 54982 54973 -9
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
|
The latest updates on your projects. Learn more about Argos notifications ↗︎
|
ashishjain0512
left a comment
ashishjain0512
left a comment
There was a problem hiding this comment.
[sisyphus-bot]
Tightly-scoped CI fix — the failure mode (preview publish runs docs:verify-version, which can't pass before the changeset PR substitutes <MERMAID_RELEASE_VERSION>) is well-explained, and the fix targets each piece narrowly. The linked failing run makes it easy to verify this matches reality.
What's working well
- 🎉 [praise] Explicit
permissions:block.contents: read+packages: writeis exactly the least-privilege scope this workflow needs, and committing it explicitly closes off any future drift if the repo's default token permissions get loosened. Bonus that this came along for the ride rather than waiting for a separate hardening PR. - 🎉 [praise] Env-var opt-out is the right shape.
ONLY_WARN_ON_VERIFY_ERROR=trueis single-purpose, scoped to this one CI step (set inline under the publish step'senv:block), andupdate-release-version.mts:20-23keeps the failure message visible — it just doesn't fail the build. So users still see which files have placeholders, they just don't block the preview publish on it. - 🎉 [praise]
pnpm pack+npm publish *.tgzsplit. Separating the artifact build from publishing makes failure diagnosis easier (you can inspect the tarball) and gives you a clean place to drop--tag previewso previews never accidentally land onlatest.
Nits
- 🟢 [nit]
npm publish *.tgzglob. The shell glob assumes exactly one.tgzin the working directory afterpnpm pack. That's almost certainly true here, but if any future step (or a leftover cache) puts another tarball in the same dir, the publish target becomes nondeterministic. Specifying the expected filename, or at least anls *.tgzsanity check before publish, would make it bulletproof. Truly a nit — feel free to ignore.
Suggestions
- 💡 [suggestion] Forward-port to
develop. Same as #7658, this targetsrelease/11.15.0directly. Worth a tracking note (or a quick PR after this lands) to bring the workflow + script changes back todevelopso the next release branch starts with the fix already in place. - 💡 [suggestion] Optional: tiny unit test for the env-var gate.
update-release-version.mts:21-23is one line of behavior change; not really worth a dedicated test, but if you wanted future-you protection from a regression here, a single vitest case assertingprocess.exit(0)whenONLY_WARN_ON_VERIFY_ERROR=trueand placeholders are present would lock it in. Definitely not blocking.
Security
No XSS or injection surface — pure CI configuration plus a one-line env-var-gated exit code. Skipping the sub-agent pass. The newly explicit permissions: block is a net positive on the workflow's security posture.
LGTM, ship it. 🚀
2 participants
📑 Summary
Note
This PR targets
release/11.15.0so we can use it straight away.The
release-preview-publish.ymlaction is often failing for recent v11 releases, see https://github.com/mermaid-js/mermaid/actions/runs/25491214960/job/74799431314 for an example.npm publishnow runspnpm docs:verify-version, which will generally fail since we'd only update the docs to fix<MERMAID_RELEASE_VERSION>with the actual changeset PR.I've updated this action to ignore this, and also bundle the
@mermaid-js/parserpackage within the@mermaid-js/mermaidpreview package we publish, so we don't have to mess with publishing a second version of that somewhere.📏 Design Decisions
See the
git logand each individual commit for more information!📋 Tasks
Make sure you
MERMAID_RELEASE_VERSIONis used for all new features.pnpm changesetand following the prompts. Changesets that add features should beminorand those that fix bugs should bepatch. Please prefix changeset messages withfeat:,fix:, orchore:.