Repository navigation
Dependency updates merge with dev in the version commit, so GitHub accepts it (version 0.5.5) - #88
Merged
Merged
Conversation
…ub accepts it; a hold for a new reason says so (version 0.5.5) When dev had moved, the update was merged with dev in a local commit and the version was committed on top; only the top commit is remade through GitHub's API, so its parent was one GitHub had never seen and the API refused it (#66 was held for this on October 27, with no comment because the hold comment was posted only once).
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.
Task: cowork-p1-repo-cleanup-001 (the automation fix for #66). Issues: none open.
The bug. When dev had moved since an automatic update was versioned, the workflow merged dev into it locally (a commit), then committed the version on top.
publish()remakes only the top commit through GitHub's API (so GitHub signs it), and its parent was the local merge commit, which GitHub had never seen: the API answered "base_tree is not a valid tree oid" four times and the update was held (#66, October 27, 06:33). Monday's first run had nothing to merge, so this path had never run.The fix. The merge is left uncommitted (
--no-commit --no-ff), so the version commit is the merge itself, with the update's head and dev as its parents, both already on GitHub. Reproduced in a throwaway repository: before, one parent GitHub doesn't have; after, two parents GitHub has, with dev's changes in.Also. A hold for a new reason now gets its own comment (one per reason, not one per pull request), so the reason is visible; the second hold of #66 had none.
Self-test 19/19 (a new case for the per-reason hold comment). Version 0.5.5, changelog heading only.