docs: say what the release setup actually is - #118
Merged
Conversation
Every STATUS line in release.yml read "to do" and every one of the five is in place. The npm trusted publisher has signed every version from 0.1.1, the release environment carries a branch policy, the version job has opened its pull request since 0.1.3, squash is the only merge method, and the ruleset names the four checks. The file says those lines are the only record of any of it, which makes a stale one worse than none, so this is the file least able to carry them. Two smaller ones in the same header. The note on anchoring the 0.x line was written for a first run that has happened, and a comment further down was hedging on whether the ruleset existed yet.
|
Warning Review limit reachedNext included review available in 10 minutes. View limit detailsLimit details: You’ve used all 2 included reviews currently available. Your 88 included PR review attempts over the past 7 days set your current allowance at 2 reviews per hour. Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. Review configuration: ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Comment |
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.
Every
STATUSline in the release workflow readto do, and all five items are in place and have been since the first releases. The header calls those lines "the only record" of setup no checkout can verify, which makes a stale one worse than none.What I checked rather than assumed: npm carries 0.1.0 through 0.1.7 with a provenance attestation on every version from 0.1.1, which is what a publish through OIDC leaves behind and what confirms the trusted publisher; the
releaseenvironment exists with a branch policy and no required reviewer; the version job has opened itschore: versionpull request on every release from 0.1.3; the repository allows squash only withPR_TITLEas the subject; and the ruleset on main requires exactlyLint,Build,Test (Node 22.x)andTest (Node 26.x).Two smaller ones in the same header, both the same kind of drift. The note on anchoring the 0.x line was written as advice for a first run that has since happened, so it now says what the tags mean rather than what to do before dispatching. And a comment further down was still hedging on whether the ruleset of item 5 existed.
The roadmap's "Still genuinely open" also listed unique visitors, which #73, #74 and #98 settled. That file is untracked, so the fix is not in this diff.
Conventional commit message, used as the title
Conventional branch name, like
feat/concise-descriptionFull check with
pnpm run checkpassedRebased off latest main
User-facing behaviour is documented in
docs/