ci: stop releases failing on issue references they cannot resolve - #202
Merged
Conversation
The github plugin's success step resolves every issue reference in the released commits and comments on it, but it looks each number up in THIS repo and drops any owner/repo qualifier. Commit messages here routinely cite upstream rdf4j issues, so a reference to eclipse-rdf4j/rdf4j#4775 became a lookup for knowledgepixels/nanopub-query#4775 and the release job exited 1: Failed step "success" of plugin "@semantic-release/github" Error: Could not resolve to an issue or pull request with the number of 4775. By then the release had already completed — tag nanopub-query-1.27.1, the GitHub release, and "Built and pushed image as nanopub/query:1.27.1" — so the only casualty was the workflow's final "Update main branch after release" step, which never ran and left main without the release commit and the snapshot bump (fixed separately by merging release into main). A re-run would not have repaired it either: with the tag already present semantic-release finds nothing releasable and skips straight past. successCommentCondition:false skips the resolution entirely (the guard in the plugin's success.js wraps the whole block), so no future upstream reference can take a release down with it. Failure reporting stays on: it opens an issue in this repo and cannot hit the same lookup. The changelog renders cross-repo references correctly either way — the entry for 1.27.1 links eclipse-rdf4j/rdf4j#4775 to the right repository. Only the commenting step has this defect. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
The 1.27.1 release job exited 1 after the release had already shipped.
What happened
@semantic-release/github's success step resolves every issue reference in the released commits and comments on it — but it looks each number up in this repo, dropping anyowner/repoqualifier. My commit message for #201 citedeclipse-rdf4j/rdf4j#4775, which became a lookup forknowledgepixels/nanopub-query#4775:Everything of substance had already completed by then — tag
nanopub-query-1.27.1, the GitHub release, andBuilt and pushed image as nanopub/query, nanopub/query:1.27.1. The only casualty was the workflow's final "Update main branch after release" step, which never ran and leftmaintwo commits behindrelease(no changelog entry, stale snapshot version). That has been repaired by mergingreleaseintomain; a re-run would not have fixed it, since with the tag present semantic-release finds nothing releasable and skips past.The change
successCommentCondition: falseon the github plugin. The guard in the plugin'ssuccess.jswraps the entire resolution block, so the failing GraphQL lookup never happens and no future upstream reference can take a release down with it.This repo cites rdf4j issues constantly, so the next stray
#Nwas a matter of time — worth removing the hazard rather than policing commit messages.Deliberately kept: failure reporting (
failComment/failTitle), which opens an issue in this repo and cannot hit the same lookup. Also unaffected is the changelog, which renders cross-repo references correctly — the 1.27.1 entry linkseclipse-rdf4j/rdf4j#4775to the right repository. Only the commenting step has this defect.Verified the config parses with the plugin list intact and exactly one
@semantic-release/githubentry:🤖 Generated with Claude Code