Support snapshot builds by dscho · Pull Request #117 · git-for-windows/gfw-helper-github-app

dscho · 2025-01-28T22:56:18Z

This PR corresponds to git-for-windows/git-for-windows-automation#109, concluding the migration of Git for Windows' snapshot builds from being built via the GitArtifacts Azure Pipeline to a combination of GitHub workflows and an orchestration in a GitHub App (concretely, this here GitForWindowsHelper GitHub App).

It implements the logic to run the tag-git workflow on push unless there is already a tag-git check run attached to the git-for-windows/git commit.

If there already is one, then the upload-snapshot workflow needs to be triggered (uploading already-released Git for Windows versions, which is the scenario where tag-git check runs already exist).

And GitForWindowsHelper also needs to learn to react to completed git-artifacts snapshot check runs on git-for-windows/git, triggering the upload-snapshot workflow also in that case. It needs to be careful, though, to verify that this is wanted, by having a peek at git-for-windows/git-artifacts' releases to see whether a corresponding tag already exists, and also by doing an ahead check to see whether the corresponding commit is actually reachable from git-for-windows/git's main branch: We do not want any snapshots to be uploaded when they correspond to a random topic branch that will never be merged.

…t-payload.js I already adjusted it at some stage, but forgot that I had manually modified the output of the `get-webhook-event-payload.js` script in my tests, and it was therefore lacking the `id` and `action` lines. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Apparently the `workspaceRoot` variable is no longer suggested (even if it seems to work), but `workspaceFolder` is. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

The idea is that that the `upload-snapshot` workflow is triggered as soon as the last `git-artifacts-*` check run has completed. Let's make it easy on myself by taking an existing webhook event that was delivered and that ideally should have triggered all that, and then develop the relevant code leaning heavily on VS Code's debugger. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

The `tag-git` workflow can be used to handle Git for Windows' snapshots via the `snapshot` Boolean that is part of its inputs. The idea is that once that workflow has completed, the `git-artifacts` workflow runs are triggered automatically via GitForWindowsHelper, one per supported CPU architecture. Now this commit introduces the logic to trigger the `upload-snapshot` workflow once all of those `git-artifacts` runs completed successfully. Naturally, we have to be careful to do this only when the snapshot has not yet been uploaded, and only when the snapshot is built from a commit that is actually on git-for-windows/git's default branch. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

When a new commit is pushed to Git for Windows' default branch, we either need to trigger a new snapshot build (namely when the `tag-git` workflow has not yet run on that commit) or upload the snapshot (this is the case when a new Git for Windows has been branch-deployed in a PR and the PR is now "merged" by pushing its tip to `main`). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

mjcheetham · 2025-01-30T15:57:56Z

GitForWindowsHelper/cascading-runs.js

+            if (!match) throw new Error(
+                `Could not parse 'summary' attribute of check-run ${req.body.check_run.id}: ${output.summary}`
+            )
+            const [, ver, commit, tagGitWorkflowRunID] = match


I've never seen this syntax before (the leading empty ,).. is it intentional?

const [, ver, .....

Yes, this skips the match[0], which would be the entire matched string (I only need the capturing groups).

mjcheetham · 2025-01-30T16:00:02Z

GitForWindowsHelper/cascading-runs.js

+                const needle =
+                    `Build Git ${ver} artifacts from commit ${commit} (tag-git run #${tagGitWorkflowRunID})`
+                const latest = runs
+                    .filter(run => run.output.summary === needle)


This filtering feels fragile. Is this the best (only, I suspect 😢) way to filter runs?

Yes, there is no other way, really. I use the title, summary and output to "store" information that links those workflow runs together.

For the record: The summary is specified in the git-artifacts workflow.

For almost eight years, Git for Windows' snapshots were hosted at https://wingit.blob.core.windows.net/files/index.html, i.e. on Azure Blobs. As of a combination of PRs [*1*], [*2*], snapshots are not only now built and deployed via GitHub Actions instead of Azure Pipelines (and ARM64 artifacts are now included, too), they are also hosted on GitHub [*3*], with the main page being hosted on GitHub Pages [*4*]. Therefore, the original link now redirects to a new location (which is also a lot easier to remember): http://gitforwindows.org/git-snapshots. Let's adjust the link to link there directly. References: *1*: git-for-windows#109 *2*: git-for-windows/gfw-helper-github-app#117 *3*: https://github.com/git-for-windows/git-snapshots/releases/ *4*: https://github.com/git-for-windows/git-snapshots/commits/gh-pages Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

For almost eight years, Git for Windows' snapshots were hosted at https://wingit.blob.core.windows.net/files/index.html, i.e. on Azure Blobs. As of a combination of PRs [*1*], [*2*], snapshots are not only now built and deployed via GitHub Actions instead of Azure Pipelines (and ARM64 artifacts are now included, too), they are also hosted on GitHub [*3*], with the main page being hosted on GitHub Pages [*4*]. Therefore, the original link now redirects to a new location (which is also a lot easier to remember): http://gitforwindows.org/git-snapshots. Let's adjust the link to link there directly. References: *1*: git-for-windows/git-for-windows-automation#109 *2*: git-for-windows/gfw-helper-github-app#117 *3*: https://github.com/git-for-windows/git-snapshots/releases/ *4*: https://github.com/git-for-windows/git-snapshots/commits/gh-pages Note that technically, we could alternatively delete the `render_release_notes_and_mail` function from `please.sh`, as it was only used in the Azure Pipeline that is no longer triggered to build the snapshots. Let's leave the code there for a bit longer, though. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

For almost eight years, Git for Windows' snapshots were hosted at https://wingit.blob.core.windows.net/files/index.html, i.e. on Azure Blobs. As of a combination of PRs [*1*], [*2*], snapshots are not only now built and deployed via GitHub Actions instead of Azure Pipelines (and ARM64 artifacts are now included, too), they are also hosted on GitHub [*3*], with the main page being hosted on GitHub Pages [*4*]. Therefore, the original link now redirects to a new location (which is also a lot easier to remember): http://gitforwindows.org/git-snapshots. Let's adjust the link to link there directly. References: *1*: git-for-windows/git-for-windows-automation#109 *2*: git-for-windows/gfw-helper-github-app#117 *3*: https://github.com/git-for-windows/git-snapshots/releases/ *4*: https://github.com/git-for-windows/git-snapshots/commits/gh-pages Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

The `SECURITY.md` document mentions Git for Windows' snapshots and helpfully provides a link. For almost eight years, these snapshots were hosted at https://wingit.blob.core.windows.net/files/index.html, i.e. on Azure Blobs. As of a combination of PRs [*1*], [*2*], snapshots are not only now built and deployed via GitHub Actions instead of Azure Pipelines (and ARM64 artifacts are now included, too), they are also hosted on GitHub [*3*], with the main page being hosted on GitHub Pages [*4*]. Therefore, the original link now redirects to a new location (which is also a lot easier to remember): http://gitforwindows.org/git-snapshots. Let's adjust the link to link there directly. References: *1*: git-for-windows/git-for-windows-automation#109 *2*: git-for-windows/gfw-helper-github-app#117 *3*: https://github.com/git-for-windows/git-snapshots/releases/ *4*: https://github.com/git-for-windows/git-snapshots/commits/gh-pages Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

The `SECURITY.md` document mentions Git for Windows' snapshots and helpfully provides a link. For almost eight years, Git for Windows' snapshots were hosted [on Azure Blobs](https://wingit.blob.core.windows.net/files/index.html). As of a combination of PRs (git-for-windows/git-for-windows-automation#109, git-for-windows/gfw-helper-github-app#117), snapshots are not only now built and deployed via GitHub Actions instead of Azure Pipelines (and ARM64 artifacts are now included, too), they are also hosted [on GitHub](https://github.com/git-for-windows/git-snapshots/releases/), with the main page being hosted [on GitHub Pages](https://github.com/git-for-windows/git-snapshots/commits/gh-pages). Therefore, the original link now redirects to a new location (which is also a lot easier to remember): http://gitforwindows.org/git-snapshots. Let's adjust the link to link there directly. This is a companion PR of git-for-windows/git-for-windows-automation#111 and of git-for-windows/build-extra#589.

dscho added 3 commits January 29, 2025 11:18

vscode(launch): avoid deprecated variable

f9d770e

Apparently the `workspaceRoot` variable is no longer suggested (even if it seems to work), but `workspaceFolder` is. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

dscho force-pushed the snapshot-builds branch from ab5000e to 660b44f Compare January 29, 2025 13:43

dscho marked this pull request as ready for review January 29, 2025 13:44

dscho changed the title ~~Snapshot builds~~ Support snapshot builds Jan 29, 2025

dscho requested a review from mjcheetham January 29, 2025 13:53

dscho force-pushed the snapshot-builds branch from 660b44f to 042ad6e Compare January 30, 2025 12:49

dscho added 4 commits January 30, 2025 13:49

Verify that the upload-snapshot workflow is triggered as desired

2c788f9

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Add a test for the push handling

f4eee78

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

dscho force-pushed the snapshot-builds branch from 042ad6e to f4eee78 Compare January 30, 2025 12:50

mjcheetham approved these changes Jan 30, 2025

View reviewed changes

dscho merged commit 8672dce into git-for-windows:main Jan 30, 2025
1 check passed

dscho deleted the snapshot-builds branch January 30, 2025 16:19

dscho mentioned this pull request Feb 5, 2025

tag-git: use the new Git for Windows snapshots URL git-for-windows/git-for-windows-automation#111

Merged

dscho mentioned this pull request Feb 5, 2025

ReleaseNotes/prerelease: use the new Git for Windows snapshots URL git-for-windows/build-extra#589

Merged

dscho mentioned this pull request Feb 5, 2025

SECURITY.md: use the new Git for Windows snapshots URL git-for-windows/git#5402

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support snapshot builds#117

Support snapshot builds#117
dscho merged 7 commits intogit-for-windows:mainfrom
dscho:snapshot-builds

dscho commented Jan 28, 2025 •

edited

Loading

Uh oh!

mjcheetham Jan 30, 2025

Uh oh!

dscho Jan 30, 2025

Uh oh!

mjcheetham Jan 30, 2025

Uh oh!

dscho Jan 30, 2025

Uh oh!

dscho Jan 30, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

dscho commented Jan 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mjcheetham Jan 30, 2025

Choose a reason for hiding this comment

Uh oh!

dscho Jan 30, 2025

Choose a reason for hiding this comment

Uh oh!

mjcheetham Jan 30, 2025

Choose a reason for hiding this comment

Uh oh!

dscho Jan 30, 2025

Choose a reason for hiding this comment

Uh oh!

dscho Jan 30, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

dscho commented Jan 28, 2025 •

edited

Loading