Repository navigation
Dependency updates: signed version commit, so an automatic update can merge on its own (version 0.4.7) - #53
Merged
Merged
Conversation
…t is signed and can merge without an extra approval (version 0.4.7)
…ge or hold, instead of relying on another run
This was referenced Oct 25, 2026
Merged
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 4f follow-up.
#48 (web app packages, patch and minor) had its version commit and a passing dispatched
build, but GitHub refused the merge: "the base branch policy prohibits the merge". Thedevruleset hasrequire_extra_approval_for_unattributed_changeson (it was on before this task, and the branch rules stay as they are), and the version commit the workflow pushed with git is unsigned (github-actions[bot], unverified).The update script now makes that commit through GitHub's API (blobs, tree, commit, ref) with the workflow's token, which GitHub signs. The local commit is still made first and the API's tree has to match it exactly, so the content is unchanged. Only files that differ from the closest parent are sent (dev, when dev is merged in). If GitHub refuses, the update is held as before.
Second commit: the update job now waits for the build it started (up to 45 minutes) and then merges or holds, then goes on to the next update. GitHub started no run when a dispatched build finished (the
workflow_runtrigger only fired for dev's push build), nor when auto-merge turned on by the workflow merged, and the hourly schedule has not fired once since #44. Theworkflow_runtrigger is removed; job timeout 120 minutes.Checked: the API path against a throwaway branch (tree identical, branch moved, branch deleted); self-test 17 of 17. Whether GitHub then treats the signed commit as attributed is shown by the next automatic update after this merges.
Version 0.4.7, heading only.