Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Latest commit

 

History

History
History
113 lines (90 loc) · 5.64 KB

File metadata and controls

113 lines (90 loc) · 5.64 KB
Copy raw file
Download raw file
Outline
Edit and raw actions

Releasing

How @atomic-testing/* packages reach npm. Publishing runs in CI on GitHub release publish via publish.yml, which builds and publishes every non-excluded, non-private package through publish.sh using npm Trusted Publishing (OIDC) — no long-lived npm token. Packages marked "private": true (the internal-* test tooling, example harness, and MUI-X fixture) are still built — the repo's own tests consume their dist — but are never published.

Cut a release

  1. Make sure main is green and has what you want to ship.
  2. Create a GitHub Release with tag vX.Y.Z (e.g. v0.85.0), targeting main.
  3. The publish workflow runs automatically: sets versions, publishes via OIDC (with provenance), and commits the version bump back to main.
  4. Verify: npm view @atomic-testing/core versionX.Y.Z.

publish.sh publishes in dependency (topological) ordercore/dom-core before the drivers that pin them, computed by scripts/publishOrder.js — and preflights that every package already exists on npm, aborting before any publish (naming the offender) if one is missing, so a forgotten bootstrap can't half-ship a release. It is also idempotent: it skips any name@version already on the registry, so re-running after a partial publish resumes instead of failing.

If a release fails

  1. Read the failed step: gh run view <run-id> --repo atomic-testing/atomic-testing --log-failed
  2. Fix forward on main, then re-fire: delete + recreate the release tag from current main (a plain re-run reuses the old tag's workflow).
  3. If some packages already published, idempotency covers the re-fire at the same version. If you prefer, bump to the next patch instead.

Changelog generation

CHANGELOG.md is generated automatically, not hand-written. The final "Commit version updates" step of publish.yml runs scripts/generateChangelog.js right after bumpVersion, so the new CHANGELOG.md section lands in the same commit as the version bump.

The script walks commit subjects since the previous release tag (the tag before the one currently being published — see the comment in the script for why) and sorts them into sections by their type prefix:

Type Section
feat Features
fix Fixes
perf Performance
refactor Refactoring
docs Documentation
build Build & Tooling
! (any type) Breaking Changes

chore, style, and test commits are intentionally excluded from every section — they're real history, just not release-notes material. See CONTRIBUTING.md for the authoring-side convention (commit/PR title format) that this depends on.

Fixing a bad entry:

  • Before it's committed: re-run node scripts/generateChangelog.js <version> --since <tag> locally to regenerate the section, then hand-edit CHANGELOG.md before the release finishes (or push a follow-up commit).
  • After it's committed: amend CHANGELOG.md directly in a normal follow-up commit — there's no need to regenerate the whole file, since only the newest section needs fixing.

Rotate CODEMOD_TOKEN (before it expires, ~yearly)

CODEMOD_TOKEN is the GitHub PAT used for checkout + the version commit-back. On expiry, releases fail at checkout with the cryptic fatal: could not read Username for 'https://github.com': terminal prompts disabled.

  1. Create a fine-grained PAT: owner atomic-testing, repo atomic-testing, Contents: Read and write. Set an expiry and a calendar reminder.
  2. gh secret set CODEMOD_TOKEN --repo atomic-testing/atomic-testing
  3. Re-fire the failed release (see above).

Add a new package

A private: true package needs no bootstrap and no trusted publisher — the preflight and publish loop both skip it (it only builds). The steps below apply to a new published package.

npm can't attach a trusted publisher before a package exists, so a new package's first publish can't use OIDC. Bootstrap it once, before the first release that includes it — otherwise publish.sh's preflight aborts the whole release (cleanly, naming the un-bootstrapped package) rather than half-publishing it:

  1. On a clean checkout of main containing the new package: pnpm install
  2. npm login (npm CLI ≥ 11.10.0; account 2FA enabled)
  3. ./bootstrap-new-package.sh <package-folder-name> — publishes a 0.0.0 placeholder and configures the trusted publisher. Enter your 2FA OTP when prompted (at the publish and npm trust steps).
  4. Confirm the new package.json has a repository field (provenance requires it).
  5. Verify: npm view @atomic-testing/<name> version0.0.0.

setup-trusted-publishers.sh reconciles trusted publishers for all published packages (auto-discovers them); re-run anytime — it's idempotent.

Gotchas

  • No NPM_TOKEN — auth is OIDC; the workflow needs id-token: write.
  • npm ≥ 11.5.1 is required for OIDC; the workflow installs npm@latest (pnpm publish shells out to npm). Stay on pnpm 10 — pnpm 11 has an OIDC regression.
  • Provenance is automatic; every package.json needs a repository.url matching the repo or publish fails E422.
  • Frozen packages (MUI 5 / MUI-X 5, ADR-005) are excluded from both publish.sh and the docs TypeDoc entry points in docs/docusaurus.config.ts — keep those two exclude lists in sync.
Morty Proxy This is a proxified and sanitized view of the page, visit original site.