Regenerate the widget gallery after CI rather than on the push - #564
Merged
Merged
Conversation
The gallery workflow ran on the push to main and committed back within two minutes, while CI's release job, ten minutes later, pushes its metadata commit with a plain `git push` from the commit it started on. The gallery commit therefore always landed first and made the release push non-fast-forward. It now runs on workflow_run once CI completes successfully for a push to main, and checks out the current main, which already carries the release commit. CI's cancel-in-progress group means no other main run is part way to a release when it pushes. The paths filter goes, since workflow_run cannot have one and a cancelled CI run can leave a widget change under the next push's run. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UAiQ9k8PXay5udWkN4vi3U
|
This was referenced Oct 1, 2026
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.



Before: the Widget Gallery workflow from #563 ran on the push to main and committed the regenerated images within about two minutes. CI's release job pushes its metadata commit about ten minutes later, with a plain
git pushfrom the commit it started on (KtsuBuildGitService.PushAsync). The gallery commit always landed first, so the release push was non-fast-forward and the release failed. The first run did exactly that: it pushed f9a2c71 on top of the #563 merge while that merge's CI was still testing.After: the gallery regenerates on
workflow_runonce CI completes successfully for a push to main. It checks out the current main, which by then already carries the release commit. CI'scancel-in-progressgroup on main means no other main run is part way to a release when the gallery pushes.How: the trigger is
workflow_run: workflows: [CI], types: [completed], branches: [main], with a jobifthat requiresworkflow_run.event == 'push'andconclusion == 'success', so pull requests, the nightly schedule, and failed or cancelled runs are skipped.workflow_dispatchstays. The paths filter is gone:workflow_runcannot have one, and a cancelled CI run can leave a widget change under the next push's run. Regenerating after every successful main run costs about two minutes and commits nothing when the pictures are unchanged. The loop and release guards are the same as before: aGITHUB_TOKENpush plus the[bot][skip ci]prefix. The rebase-and-retry push loop stays, in case a manual dispatch runs while a release is in progress. CLAUDE.md and the WidgetGallery README are updated to match. actionlint is clean.This PR's own merge tests the new order: CI and its release run first, then the gallery.
🤖 Generated with Claude Code
https://claude.ai/code/session_01UAiQ9k8PXay5udWkN4vi3U
Generated by Claude Code