Conversation
PrepareJob.yml -------------- 'FindPullRequest' looked up a merged Pull Request whose base is the release branch, but it ran for every merge commit. A merge commit pushed to the development branch comes from a Pull Request based on the development branch, so the search returned an empty list and the step - and with it the whole 'Prepare' job - failed. Guard the step with 'is_release_commit', which 'Classify' already computes as 'is_merge_commit' restricted to the main and version branches, and which 'TriggerTaggedRelease' keys off too. This answers the TODO that sat right above the step. The search itself is now exact. It lists every Pull Request *containing* the second parent, which can be more than one - an older release Pull Request built from an ancestor also matches - and the code then took the first entry in an unordered list. The second parent (father) of a merge commit is the head commit of the merged branch, so the candidates are reduced to those whose 'headRefOid' equals it. If a Pull Request was closed and recreated from the same branch, both share a head commit and the most recently merged one is used, with a warning naming both. No match is now an error that lists the candidates instead of falling through to the literal 'null': 'gh pr list --json' returns an empty JSON array, not an empty string, so the previous guard never triggered. Everything stays derived from the commit graph. Deriving the Pull Request from the merge commit's message instead was tried and rejected: that message is free text - editable in the merge dialog, arbitrary for a local merge - so a subject ending in '(#123)' could select an issue number or an unrelated Pull Request and tag a wrong release. The v0.38.0 release merge of pyVHDLModel shows both sides of it: its subject is plain 'v0.38.0' with no number to parse, while its second parent '61bd8eb' equals the 'headRefOid' of Pull Request #133 exactly. CleanupArtifacts.yml -------------------- The second delete step guarded itself with 'steps.compute2', but passed the names computed by 'steps.compute'. So it re-deleted the first set - already deleted by the first step, and masked by 'continue-on-error' - while the artifacts named by 'artifact-json-ids2' survived. Present since the workflow was introduced, but only visible now that 'CompletePipeline' relies on the second set to delete the package artifact on non-release runs. Co-Authored-By: Patrick Lehmann <Paebbels@gmail.com>
Not up to standards ⛔🟢 Coverage
|
| Metric | Results |
|---|---|
| Coverage variation | ✅ +0.00% coverage variation |
| Diff coverage | ✅ 100.00% diff coverage |
Coverage variation details
Coverable lines Covered lines Coverage Common ancestor commit (473db0b) 45 41 91.11% Head commit (f6f6430) 45 (+0) 41 (+0) 91.11% (+0.00%) Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch:
<coverage of head commit> - <coverage of common ancestor commit>
Diff coverage details
Coverable lines Covered lines Diff coverage Pull request (#243) 1 1 100.00% Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified:
<covered lines added or modified>/<coverable lines added or modified> * 100%
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
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
2 participants
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.
Changes
PrepareJob.ymlassociates the Pull Request exactly instead of taking the first search hit.gh pr list --search <sha>lists every merged Pull Request that contains that commit, so it can return more than one — an older release Pull Request built from an ancestor matches just as well — and the code then took.[0]of an unordered list.The second parent (father) of a merge commit is the head commit of the merged branch, so the candidates are now reduced to those whose
headRefOidequals it:If a Pull Request was closed and recreated from the same branch — rare, but possible — both share a head commit, and the most recently merged one is used, with a warning naming both. Everything stays derived from the commit graph.
Bug Fixes
PrepareJob.yml:Preparefailed for every merge commit on the development branch. The step Find merged PullRequest from second parent searches a merged Pull Request whose base is the release branch, but it was guarded byis_merge_commitalone. A merge commit pushed to the development branch originates from a Pull Request based on the development branch, so the search can never match and the step exits 1 — taking the wholePreparejob, and with it the run, down.Downstream effect: on a development-branch merge,
Prepare.outputs.versionis now empty, as it already was for regular commits.VersionCheckis guarded byneeds.Prepare.outputs.version != ''and is therefore correctly skipped there — it only ever ran on such pushes by way of the match above. On the release path nothing changes.PrepareJob.yml: a search without a hit was not detected.gh pr list --json …returns an empty JSON array, not an empty string, so[[ "${PULL_REQUESTS}" == "" ]]never triggered. A no-match fell through tojq .[0].title→ the literalnull, and only the later regexp check reported it — as a confusing complaint about a title namednull. No match is now an error that lists the candidates the search did return.CleanupArtifacts.yml: the second delete step deleted the first set again. The step guarded itself withsteps.compute2but passed the names resolved bysteps.compute:Documentation
doc/JobTemplate/Setup/PrepareJob.rst— the Behavior topic now states that step 4 runs for release commits only, and how the pull-request is identified (headRefOidequal to the second parent, newest wins on a tie).Related Issues and Pull-Requests