chore: publish from CI via Trusted Publishers, and document the fork - #1
Merged
Conversation
MaximBelov
added a commit
that referenced
this pull request
Aug 14, 2026
…able's PRs The matrix was 18.x and 16.x. Node 16 went end-of-life in September 2023 and 18 in April 2025, while CD publishes on Node 24 and the projects installing this CLI globally run 24 as well -- so CI was testing two runtimes nobody uses and not the one everybody does, twice over. One job on 24 replaces it. Note that packages/@ionic/cli still declares engines.node >= 16.0.0, inherited from upstream. That claim is now unverified rather than verified-on-EOL; raising it is a change to the package's contract and is left as a separate decision. Also fixes the trigger. The filter was branches-ignore: [stable] on both events, and for pull_request that filters on the base branch -- so pull requests into stable, the release branch, were the only ones that got no checks at all. That is why PR #1 reported no CI. Pull requests are now checked whatever they target, and pushes are checked on the two long-lived branches. setup-node's own npm cache replaces the hand-rolled actions/cache step, and the actions move off v3. Verified with actionlint.
The release pipeline was inherited from upstream and could not work in this fork. lerna version pushes a release commit and tag straight to stable, which is protected; there is no NPM_TOKEN secret here, so NODE_AUTH_TOKEN would have been an empty string; and 8.0.0 was in fact published by hand, with no provenance. publish:ci is now just npm publish, so nothing writes back to a protected branch, and authentication moves to npm's Trusted Publishers (OIDC) -- no token to store, and provenance attached automatically. Releasing is two steps: a human bumps the version in a pull request, and merging it publishes. A merge that does not change the version is not a release, so CD checks npm first and skips. The Docker steps go. They tagged the image from upstream's published version, unrelated to anything this fork releases, and nothing consumes the image. repository, homepage and bugs now point at this repository, which provenance requires as well. The README gains a short section on why the fork exists. CI dropped its Node 16 and 18 matrix -- both end-of-life, while CD publishes on 24 and every consumer installs on 24 -- for one job on 24. Its trigger was branches-ignore: [stable], and for pull_request that filters the base branch, so pull requests into stable were the only ones that got no checks at all. setup-node's own npm cache replaces the hand-rolled cache step. Verified with actionlint.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this does
Makes CI publish the package instead of a person, and points the npm page at this repository rather than upstream's.
Releasing becomes two steps: someone bumps the version in a pull request, and merging that PR publishes it. A merge that does not change the version is not a release — CD checks npm first and skips.
Why the old pipeline had to be replaced rather than fixed
It could not have worked here at all:
lerna versionpushes a release commit and a tag straight tostable, which is now protected.NPM_TOKENsecret in this repository, soNODE_AUTH_TOKENwould have been an empty string.8.0.0was in fact published by hand — npm records a personal account as the publisher and the tarball carries no provenance.So
publish:ciis now justnpm publish, and authentication moves to npm's Trusted Publishers (OIDC): nothing to store, and provenance is attached automatically.The Docker steps go. They tagged the image from
npm info @ionic/cli— upstream's version, unrelated to what this fork publishes — and nothing consumes the image.CI
The matrix was Node 16 and 18, both end-of-life, while CD publishes on 24 and everyone installing this CLI runs 24. One job on 24 replaces it. (
engines.nodestill says>=16.0.0, inherited from upstream — raising it changes the package's contract, so that is a separate decision.)The trigger was
branches-ignore: [stable], and forpull_requestthat filters the base branch — so pull requests intostablewere the only ones getting no checks at all. That is why this PR had none when it was opened.Checks
actionlinton both workflows