docs(release): unpark the release workflow and correct its setup status - #8
Merged
Conversation
The workflow was still named "draft, parked, not enabled" and its header said it cannot publish until someone wires the secrets. Both are false now: 0.1.0 is on the registry and the provenance flow is wired. A maintainer reading either would conclude releasing is not possible. Also records two things the next releaser would otherwise hit. The generated release notes diff against the previous tag, and 0.1.0 was published outside this workflow so no tag existed; v0.1.0 has been backfilled onto 265809b. And the version is a workflow input, so bumping package.json by hand before dispatching produces a release commit with no version change in it. The one-time setup section is kept rather than deleted, marked as done, since it is the checklist to re-run if the org, token or environment is rebuilt.
0.1.0 reached npm by a manual publish that bypassed this workflow, so its presence is not evidence the workflow can publish. The previous wording read the artifact as proof of the setup the artifact had skipped. Measured: repos/sidebase/streamctl/environments returns zero environments and the repo has no secrets, so the `release` environment does not exist. GitHub creates a referenced-but-missing environment unprotected and secretless, so an unconfigured dispatch loses its approval gate and then fails at publish on auth, before the push, leaving origin untouched. NPM_TOKEN may still exist as an org secret, which is not readable without org admin, so this records the check to run rather than asserting the token is absent.
kboshold
changed the title
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
Corrects what the release path claims about itself. Docs and comments only, no behaviour change.
Release (draft, parked, not enabled)and its header said it cannot publish until someone wires the secrets. Renamed toReleaseand the header rewritten.v0.1.0has been backfilled onto265809b, the last commit carrying that version.package.jsonfirst.The workflow stays
workflow_dispatch-only and scoped to thereleaseenvironment.Why
Two claims here were wrong in opposite directions, and both would mislead whoever ships next.
The workflow said releasing was impossible.
0.1.0is on the registry and the provenance flow is written, so a maintainer reading the name or the old runbook header would have concluded the opposite of the truth.Then the first draft of this PR overcorrected and marked the setup done, reasoning from
0.1.0being published. That does not follow:0.1.0was published by hand, outside this workflow, so it is evidence the workflow was bypassed, not evidence it works. Checking directly:The
releaseenvironment does not exist. That fails quietly rather than loudly: GitHub creates a referenced-but-missing environment with no protection rules and no secrets, so a dispatch today would skip its own approval gate and reachpnpm publishwith an emptyNODE_AUTH_TOKEN. It dies there, which is before the push, so origin stays untouched and no orphan tag appears.NPM_TOKENmay still exist as an org secret, which is not readable without org admin. So the runbook records the check to run rather than claiming the token is missing.