Move to a new org for GitGitGadget's manually-triggered workflows#3
Merged
Move to a new org for GitGitGadget's manually-triggered workflows#3
Conversation
The Git maintainer frequently pushes out dozens of branches at the same time. Every of those branches triggers their own CI run, spawning almost 50 jobs, with an overall runtime of over 8h (!) which would amortize to a shorter wall-clock time if only the concurrency limit of 20 parallel jobs was not depleted so efficiently. These concurrency limits are org-wide on GitHub. That is, when dozens of workflow runs are partially running, partially queued up, in `gitgitgadget/git`, all new workflow runs in `gitgitgadget/gitgitgadget-workflows` are queued and will have to wait their turn. In combination, this leads to a frequent starvation of GitHub Actions resources, which means: even short tasks (like the `sync-ref` workflow) won't run for several hours in such situations. To remedy that, I forked the `gitgitgadget-workflows` repository into a new org: `gitgitgadget-workflows. That way, the workflows like `sync-ref` do not have to wait for CI/PR runs to finish in `gitgitgadget/git`. This PR adjusts GitGitGadget's GitHub App to trigger the `sync-ref` workflow in that org. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Member
Author
By the way, once the work I am doing over in gitgitgadget/gitgitgadget#1392 is completed, I also plan on moving the |
mjcheetham
approved these changes
Aug 18, 2025
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.
The Git maintainer frequently pushes out dozens of branches at the same time. Every of those branches triggers their own CI run, spawning almost 50 jobs, with an overall runtime of over 8h (!) which would amortize to a shorter wall-clock time if only the concurrency limit of 20 parallel jobs was not depleted so efficiently.
These concurrency limits are org-wide on GitHub. That is, when dozens of workflow runs are partially running, partially queued up, in
gitgitgadget/git, all new workflow runs ingitgitgadget/gitgitgadget-workflowsare queued and will have to wait their turn.In combination, this leads to a frequent starvation of GitHub Actions resources, which means: even short tasks (like the
sync-refworkflow) won't run for several hours in such situations.To remedy that, I forked the
gitgitgadget-workflowsrepository into a new org:gitgitgadget-workflows. That way, the workflows likesync-refdo not have to wait for CI/PR runs to finish ingitgitgadget/git`.This PR adjusts GitGitGadget's GitHub App to trigger the
sync-refworkflow in that org.My long-term plan is to rename the forked repository, move the repository from
gitgitgadget, and then delete the (renamed) fork. This somewhat complex process is necessary so as not to disrupt GitGitGadget while this here PR is not yet merged.