ci: adopt Changesets with a gated production release - #16
Conversation
Merging a version PR now only prepares a release; publishing to npm requires approving the `production` GitHub environment, which re-runs the full CI suite (lint/typecheck/test/publint/pack) against the exact SHA being published before `changeset publish` runs. Replaces the hand-cut GitHub Release trigger with push-to-main + Changesets, reusing the existing npm OIDC trusted publishing setup.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1c24f79e49
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| name: Release | ||
| needs: validate | ||
| runs-on: ubuntu-latest | ||
| environment: production |
There was a problem hiding this comment.
When a normal PR carrying a changeset is merged, this job must open or update the Version Packages PR, but GitHub applies required-reviewer environment protection before starting any step in the job. Putting environment: production here therefore makes PR creation and updates wait for production approval as well; approval cannot be limited to the changeset publish branch inside changesets/action, so routine merges no longer drive the advertised Changesets flow automatically. Split PR maintenance from the environment-protected publishing path.
AGENTS.md reference: AGENTS.md:L15-L15
Useful? React with 👍 / 👎.
1 participant
What
.changeset/config.json(access: public,baseBranch: main), pluspnpm changeset/pnpm run ci:publishscripts.npm pack --dry-run) into.github/workflows/reusable-ci.ymlsoci.ymlandpublish.ymlrun the identical checks.publish.yml: trigger on push tomaininstead ofrelease: published. Avalidatejob runs the reusable CI suite;release(needs: validate) then runschangesets/action@v1, which opens/updates a version PR or, once that PR is merged, runschangeset publish. Gatingreleaseonvalidatein the same run means the exact SHA about to publish has passed full CI - not a possibly-stale separate run.productionGitHub environment (configured via the API, required reviewer: repo owner) torelease, so merging the version PR only prepares a release; publishing still requires approving the environment deployment.publishConfig.access/provenancetopackage.jsonto match the pattern used elsewhere in the org (e.g.typescript-teslemetry's packages).Registry-side setting to verify
npm trusted publishing (OIDC) is configured per-package on npmjs.com. This PR keeps the same repo + workflow filename (
.github/workflows/publish.yml), so the existing trusted publisher entry fortesla-fleet-apishould still match, but please confirm on npmjs.com (package Settings → Trusted Publisher) that it points atTeslemetry/node-tesla-fleet-api/.github/workflows/publish.yml, and consider restricting it to theproductionenvironment now that one exists.