Support snapshot builds #117
Merged
Conversation
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
…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 <[email protected]>
Apparently the `workspaceRoot` variable is no longer suggested (even if it seems to work), but `workspaceFolder` is. Signed-off-by: Johannes Schindelin <[email protected]>
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 <[email protected]>
dscho
force-pushed
the
snapshot-builds
branch
from
ab5000e to
660b44f
Compare
dscho
force-pushed
the
snapshot-builds
branch
from
660b44f to
042ad6e
Compare
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 <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
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 <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
force-pushed
the
snapshot-builds
branch
from
042ad6e to
f4eee78
Compare
mjcheetham
approved these changes
Jan 30, 2025
| 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 |
There was a problem hiding this comment.
I've never seen this syntax before (the leading empty ,).. is it intentional?
const [, ver, .....There was a problem hiding this comment.
Yes, this skips the match[0], which would be the entire matched string (I only need the capturing groups).
Comment on lines
+191
to
+194
| const needle = | ||
| `Build Git ${ver} artifacts from commit ${commit} (tag-git run #${tagGitWorkflowRunID})` | ||
| const latest = runs | ||
| .filter(run => run.output.summary === needle) |
There was a problem hiding this comment.
This filtering feels fragile. Is this the best (only, I suspect 😢) way to filter runs?
There was a problem hiding this comment.
Yes, there is no other way, really. I use the title, summary and output to "store" information that links those workflow runs together.
There was a problem hiding this comment.
For the record: The summary is specified in the git-artifacts workflow.
dscho
added a commit
to dscho/git-for-windows-automation
that referenced
this pull request
Feb 5, 2025
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 <[email protected]>
dscho
added a commit
to dscho/git-for-windows-automation
that referenced
this pull request
Feb 5, 2025
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 <[email protected]>
dscho
added a commit
to dscho/build-extra
that referenced
this pull request
Feb 5, 2025
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 <[email protected]>
dscho
added a commit
to git-for-windows/git-for-windows.github.io
that referenced
this pull request
Feb 5, 2025
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 <[email protected]>
dscho
added a commit
to dscho/git
that referenced
this pull request
Feb 5, 2025
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 <[email protected]>
dscho
added a commit
to git-for-windows/git
that referenced
this pull request
Feb 6, 2025
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.
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 corresponds to git-for-windows/git-for-windows-automation#109, concluding the migration of Git for Windows' snapshot builds from being built via the
GitArtifactsAzure 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-gitworkflow onpushunless there is already atag-gitcheck run attached to thegit-for-windows/gitcommit.If there already is one, then the
upload-snapshotworkflow needs to be triggered (uploading already-released Git for Windows versions, which is the scenario wheretag-gitcheck runs already exist).And GitForWindowsHelper also needs to learn to react to completed
git-artifactssnapshot check runs ongit-for-windows/git, triggering theupload-snapshotworkflow also in that case. It needs to be careful, though, to verify that this is wanted, by having a peek atgit-for-windows/git-artifacts' releases to see whether a corresponding tag already exists, and also by doing anaheadcheck to see whether the corresponding commit is actually reachable fromgit-for-windows/git'smainbranch: We do not want any snapshots to be uploaded when they correspond to a random topic branch that will never be merged.