Merged
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
cd813b7 to
b3efaa7
Compare
This is a continuation of the work done in gitgitgadget/gitgitgadget#1392. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
One of the really nice things about the Azure Pipelines was that they would automatically show PR Checks when they were running. This gave some sort of pleasing, visual feedback when `/submit`-ing patch series. Let's have the same even in the new world, where the PR comment is handled by a GitHub workflow running in a completely separate GitHub org, and not connected with the PR in any official capacity. Note: If we do not specify `output[text]` in the final update, the text that was specified when creating the Check Run will be _forgotten_. This is arguably a bug in Actions, and given the recent history of that product it probably won't get fixed, so we work around it here by simply specifying the entire `output` _again_. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The newly-added workflows update global state. This global state is held in Git notes in the `gitgitgadget/git` repository and is updated in reaction to updates to the Git mailing list mirror and to the `seen` branch. While there is now logic in GitGitGadget's Git notes handling to allow for "distributed updates", it makes more sense to hold off from trying to perform (nearly-)identical updates in parallel. Note: In the case of `handle-pr-comment` and `handle-pr-push`, let's be mindful that it should be possible to handle different PRs concurrently, which is definitely a change of behavior from the current Azure Pipelines setup, where only one job can be run at any given time, _across_ Azure Pipelines (for example, a lengthy `Update GitGitGadget's PRs` run can easily delay any `/submit` from being processed). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
b3efaa7 to
52c2c9d
Compare
dscho
added a commit
to dscho/gitgitgadget
that referenced
this pull request
Aug 24, 2025
This is the culmination of all the preparation: The first GitHub Action
that will be used in a GitHub workflow that will replace these trusty
Azure Pipelines we used for so long:
- GitGitGadget PR Handler:
https://dev.azure.com/gitgitgadget/git/_build?definitionId=3
- GitGitGadget PR Handler (git):
https://dev.azure.com/gitgitgadget/git/_build?definitionId=13
- GitGitGadget PR Handler (dscho):
https://dev.azure.com/gitgitgadget/git/_build?definitionId=12
Note that this Action receives the full `pr-comment-url` as Action
input; Readers might wonder why the Action cannot receive the
information in a more fine-grained manner, seeing as the `github`
context of a GitHub workflow triggered by a new PR comment already has
all the necessary values. But this would require adding a
GitGitGadget-specific workflow to the main `git/git` repository,
something that was considered in
gitgitgadget#861 but which would
be _extremely_ difficult to convince the core Git contributors to
accept. Therefore, the GitHub workflow using this Action will be a
`workflow_dispatch`-triggered one, for more details see
gitgitgadget-workflows/gitgitgadget-workflows#1.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to dscho/gitgitgadget
that referenced
this pull request
Aug 24, 2025
This GitHub Action is designed to implement the functionality that is currently handled when pushing to PRs by these Azure Pipelines: - GitGitGadget PR Handler: https://dev.azure.com/gitgitgadget/git/_build?definitionId=3 - GitGitGadget PR Handler (git): https://dev.azure.com/gitgitgadget/git/_build?definitionId=13 - GitGitGadget PR Handler (dscho): https://dev.azure.com/gitgitgadget/git/_build?definitionId=12 This Action will be used in a GitHub workflow that will replace those trusty Azure Pipelines we used for so long. This workflow lives in a different org, for full details see gitgitgadget-workflows/gitgitgadget-workflows#1. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to dscho/gitgitgadget
that referenced
this pull request
Aug 24, 2025
The idea is to take over the job of the "Mirror Git List to GitGitGadget's PRs" Azure Pipeline over at https://dev.azure.com/gitgitgadget/git/_build?definitionId=5. This will obviously require a GitHub workflow, too, which is added in gitgitgadget-workflows/gitgitgadget-workflows#1 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to dscho/gitgitgadget
that referenced
this pull request
Aug 24, 2025
The idea is to take over the job of the "Update GitGitGadget's PRs" Azure Pipeline over at https://dev.azure.com/gitgitgadget/git/_build?definitionId=2. This will obviously require a GitHub workflow, which is added in gitgitgadget-workflows/gitgitgadget-workflows#1 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to dscho/gitgitgadget
that referenced
this pull request
Aug 24, 2025
The idea is to take over the job of the "Update GitGitGadget's commit to mail notes" Azure Pipeline over at https://dev.azure.com/gitgitgadget/git/_build?definitionId=9, making use of the just-ported logic in `CIHelper`. This will obviously require a GitHub workflow, too, which is added in gitgitgadget-workflows/gitgitgadget-workflows#1 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
I have finished reviewing. Will need to set up a reference implementation for other projects to model off of at some point. |
dscho
added a commit
to dscho/gitgitgadget
that referenced
this pull request
Aug 26, 2025
The idea is to take over the job of the "Mirror Git List to GitGitGadget's PRs" Azure Pipeline over at https://dev.azure.com/gitgitgadget/git/_build?definitionId=5. This will obviously require a GitHub workflow, too, which is added in gitgitgadget-workflows/gitgitgadget-workflows#1 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to dscho/gitgitgadget
that referenced
this pull request
Aug 26, 2025
The idea is to take over the job of the "Update GitGitGadget's PRs" Azure Pipeline over at https://dev.azure.com/gitgitgadget/git/_build?definitionId=2. This will obviously require a GitHub workflow, which is added in gitgitgadget-workflows/gitgitgadget-workflows#1 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to dscho/gitgitgadget
that referenced
this pull request
Aug 26, 2025
The idea is to take over the job of the "Update GitGitGadget's commit to mail notes" Azure Pipeline over at https://dev.azure.com/gitgitgadget/git/_build?definitionId=9, making use of the just-ported logic in `CIHelper`. This will obviously require a GitHub workflow, too, which is added in gitgitgadget-workflows/gitgitgadget-workflows#1 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Author
I've started that process with https://github.com/cygwingitgadget/cygwin-patches-list-mirror; My plan is to turn this into a fully-working GitGitGadget setup to contribute patches to Cygwin. |
f183fbd to
52c2c9d
Compare
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.
This PR is part 5 of addressing gitgitgadget/gitgitgadget#609, and it is stacked on top of gitgitgadget/gitgitgadget#1980, gitgitgadget/gitgitgadget#1981, gitgitgadget/gitgitgadget#1982, and gitgitgadget/gitgitgadget#1983, therefore I will leave this in draft mode until those PRs are merged.
For each GitHub Actions added by those PRs, this here PR adds a corresponding, minimal GitHub workflow. These will need to be triggered via GitGitGadget's existing GitHub App.
Since I was slightly worried about a time penalty incurred by switching from the persistent
gitgitgadget/gitandgitgitgadget/git-mailing-list-mirrorclones in the Azure Pipelines to ephemeral, partial clones in the GitHub workflows, I have run these (mostly in dry-run mode, to avoid updates that would duplicate already-existing ones), for comparison with the existing Azure Pipelines:handle-pr-commenthandle-pr-pushhandle-new-mailsupdate-prsupdate-mail-to-commit-notesCaveat: The timing comparisons are not exactly apples to apples, as I haven't paid full attention to start from the exact same preconditions (for example, the Git mailing list mirror repository contained more emails during the test runs than when the Azure Pipelines ran). In some cases, I even used different PRs because the actual expensive parts were in the setup phase, anyway, the PR-specific logic took a comparatively tiny fraction of the time. In any case, I was mostly interested in ballpark estimates, to gauge roughly how much of a penalty the transition will incur.
While it'd have been fantastic if e.g. the
handle-new-mailsjob would not have taken twice as long as the corresponding Azure Pipeline run, we need to take that time with a grain of salt: The test run probably handled many more emails than the Azure Pipeline because I "rewound" the state so that more code paths would be exercised than the "oh hey, we're up to date" one.Having said that, the GitGitGadget functionality where swiftness is most crucial is the one where users interact directly, i.e. PR pushes and comments. In those scenarios, it seems that the difference is relatively small.
Since
update-prsandupdate-mail-to-commit-notesare to be triggered by updates to theseenbranch, which seem to be less than a dozen times per week, those time differences do not worry me much.The most concerning difference is that of
handle-new-emails, which is to be triggered by updates to thegit-mailing-list-mirrorrepository. Looking at the monthly insights of that repository, the frequency seems to be roughly one update every 20 minutes on average. Which, during more active times, amounts to a lot more frequent updates. If it should turn out in practice that the workflow does, indeed, take around two minutes for every run, I'll need to dig in to figure out how to accelerate this. But then, the 2m6s run mentioned above handled the "What's cooking" email, and there is a 44s jump right before that which may mean that there's a lot of inefficient Git object fetching going on (getting and updating Git notes in a partial repository are usually individual roundtrips...).