Skip to content

Move to a new org for GitGitGadget's manually-triggered workflows #3

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 18, 2025

Conversation

dscho
Copy link
Member

@dscho dscho commented Aug 18, 2025

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-refdo not have to wait for CI/PR runs to finish ingitgitgadget/git`.

This PR adjusts GitGitGadget's GitHub App to trigger the sync-ref workflow 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.

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 <[email protected]>
@dscho dscho requested review from mjcheetham and webstech August 18, 2025 12:18
@dscho dscho self-assigned this Aug 18, 2025
@dscho
Copy link
Member Author

dscho commented Aug 18, 2025

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.

By the way, once the work I am doing over in gitgitgadget/gitgitgadget#1392 is completed, I also plan on moving the gitgitgadget repository (and renaming it, probably to gitgitgadget-action).

@dscho dscho merged commit b0287bc into main Aug 18, 2025
1 check passed
@dscho dscho deleted the move-to-workflows-org branch August 18, 2025 16:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants