ci(release): generalize post-release jobs to every package in the workspace - #18
Merged
Conversation
…jobs to every package
Collect what this run released grepped for a tag matching ^trilean@ specifically,
a leftover from when the workspace held one package. With trilean-sql added, its
own new-package release tag never matched that pattern, so notify-hive, the
GitHub Packages mirror, and both attestation jobs silently skipped for it --
confirmed directly: trilean-sql@1.0.0 published to npm correctly, since the
orchestrator's own per-package publish never depended on this step, but none of
the four downstream jobs ran.
Collect what this run released now builds a JSON array of every package this run
released, from every new tag rather than one hardcoded name, matching how
documents.js already solves the identical problem for its own many packages.
notify-hive loops the array with one dispatch per package rather than a single
hardcoded payload; the three per-package jobs (GitHub Packages mirror, and both
attestation legs) each gain a `strategy: matrix` fanning out one leg per released
package, working against packages/${{ matrix.name }} and matrix.tag instead of a
single hardcoded package and tag.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
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
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 broke
trilean-sql's first release (`#14`) confirmed a gap the release-collection step's own hardcoded design predicted it would have: it published to npm correctly (semantic-release-workspace's per-package publish never depended on this step), but its GitHub Packages mirror, both SBOM/build-provenance attestations, and the `notify-hive` dispatch to novus-power/hive all silently skipped.
Root cause, from the actual run log: `Collect what this run released` diffs tags and does `grep '^trilean@'` -- a literal, hardcoded prefix left over from when the workspace held exactly one package. A new `trilean-sql@1.0.0` tag simply doesn't match it, so the step reported `released=false`, and every downstream job (all gated on that single boolean) skipped.
The fix
`Collect what this run released` now builds a JSON array of every package this run actually released -- `[{name, version, tag}, ...]` -- from every new tag rather than one hardcoded name, following the exact pattern `documents.js` already uses for its own many packages. The four downstream jobs adapt accordingly:
Verified locally: the collection script's own logic (including the "no matching package, skip with a warning" branch for an unrelated tag) and the `notify-hive` dispatch loop (including the empty-matrix case) against simulated matrices before pushing. The next real trilean or trilean-sql release will be the actual end-to-end proof.