Support embargoed tag-git and git-artifacts workflow runs
#133
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
For embargoed Git for Windows versions, we already have a well-established paradigm where the `git-sdk-32`, `git-sdk-64`, `build-extra` and `MINGW-packages` worktrees are not initialized with the current state of the `main` branch, but with the current state of the `git-<version>` branches, the "release branches". Let's teach the `git-artifacts` workflow to optionally use the same paradigm. This supersedes the strategy we established earlier when building from a tag, where the `build-extra` revision to use could be specified; This strategy was incomplete, as it left out e.g. `MINGW-packages` which most likely _also_ wanted to be at a specific revision rather than blindly using the tip commit of the `main` branch. Signed-off-by: Johannes Schindelin <[email protected]>
When building MinGit backports from tags (identified by specifying "mingit" or "mingit mingit-busybox" as `artifacts` value), we need to use a different default release branch name, e.g. `mingit-2.43.x-releases`. While at it, also adjust the check run name to reflect that this is not a regular Git for Windows build but a MinGit one. Signed-off-by: Johannes Schindelin <[email protected]>
When building in a fork of `git-for-windows-automation`, we should also pull the `git-sdk-32`, `git-sdk-64`, `build-extra` and `MINGW-packages` repositories from the same user's (or org's) forked repositories. Signed-off-by: Johannes Schindelin <[email protected]>
On GitHub, forks of public repositories cannot be private, of course, but a fork can be created other than by clicking GitHub's `Fork` button... Signed-off-by: Johannes Schindelin <[email protected]>
… needed
In private tests, this command seems to have failed consistently, with
this error message:
+ git commit -s -m 'mingw-w64-git: new version (test)' PKGBUILD
[test e641948] mingw-w64-git: new version (test)
1 file changed, 2 insertions(+), 2 deletions(-)
+ git bundle create /d/a/test/test/artifacts/MINGW-packages.bundle 'test^..test'
error: pack-objects died
Error: Process completed with exit code 1.
After extensive debugging of this elusive problem (it is relatively
consistent when running inside a workflow step, but running it
interactively via `action-tmate` succeeds every single time), the most
plausible explanation is that Defender doing its thing, and that results
in a "Permission Denied" problem.
Calling the command with `GIT_TRACE2_EVENT` enabled seems to work around
the problem, and just in case it does not, let's add a loop to try a
couple more times should the command fail.
In the end, just validate the bundle to make sure that it was created
correctly.
Signed-off-by: Johannes Schindelin <[email protected]>
One of the things in the Git project that you either grow to love or instead to wish away is the somewhat consistent tendency to be inconsistent. This commit concerns itself with the fact that the release notes of v2.49.1 are stored in a `.txt` file in `Documentation/RelNotes/`. All other files in that directory have the `.adoc` extension ever since that ill-executed rename of 1f010d6bdf (doc: use .adoc extension for AsciiDoc files, 2025-01-20). Funnily enough, this is only true for the revision tagged as v2.49.1, but the one tagged as v2.50.1 has them renamed to `.adoc` files. I'll just do what I always do: Deal with the fall-out in a pragmatic way, as there isn't really any good alternative to that approach. Signed-off-by: Johannes Schindelin <[email protected]>
The original is Markdown, but in the announcement mail and in the tag message, we do not use Markdown, so the fact that this line is a header is lost. Let's append a colon at the end of that line to make the message flow a bit easier. Signed-off-by: Johannes Schindelin <[email protected]>
The `-C` method still works, but will (hopefully) soon be disabled by default, by flipping the default of the `safe.bareDirectory` config setting. Signed-off-by: Johannes Schindelin <[email protected]>
It is true that regular Git for Windows releases always rebase to the
corresponding upstream version.
However, embargoed MinGit releases _merge_ the upstream versions
instead, for simplicity.
And the plan is to do the same for embargoed Git for Windows releases,
too, as that will make future rebases much easier: if embargoed upstream
versions are merged into embargoed Git for Windows releases, those
latter can easily be merged into Git for Windows' `main` branch without
duplicating patches in `main^{/Start.the.merging-rebase}..main`.
Signed-off-by: Johannes Schindelin <[email protected]>
Whether rebasing to, merging-rebasing to, or merging an upstream tag, or not integrating an upstream tag at all, we must figure out the best base tag. So far, I tried several strategies: - `--first-parent`: This works only for merging-rebases - `--exclude='*.windows.*'`: This works if integrating an upstream tag, but not when a `.windows.2` version is desired - calling `git describe` twice: first to figure out the reachable upstream tag that is closest to the revision, and then calling it a second time, this time allowing for a Git for Windows tag. If the two searches came up with different results, pick the most recent one. Unfortunately that did not work. Its logic relies on the date when the Git version the downstream Git for Windows version was tagged. This broke down in the case of v2.50.1, which was tagged before I could release v2.50.0.windows.1. Let's just instead pick the higher version number by leveraging the `version_compare` function I developed in git-for-windows/build-extra@1418ee7e8e (git-update: do not suggest downgrading from an -rc version, 2017-10-26) and that has been subsequently been enhanced in that repository. Signed-off-by: Johannes Schindelin <[email protected]>
In the past, I built MinGit backports by crafting tags manually, then letting an Azure Pipeline pick that tag up, automatically determine the corresponding `mingit-2.<N>.x-releases` release branch name, and then build the MinGit assets. However, with the nice `tag-git` and `git-artifacts` GitHub workflows already doing much of what is needed to streamline the process, we can easily adjust both workflows to allow ticking a `mingit-only` checkbox and use the exact same flow for MinGit backports as for embargoed Git for Windows releases: open a PR with the changes, start the `tag-git` workflow, and once it finishes, kick off corresponding `git-artifacts` workflow runs, one for each supported architecture. The main adjustment is this `mingit-only` checkbox, writing the `mingit-only` file to the `bundle-artifacts` artifact if set, and crafting slightly a different release notes/tag title than regular Git for Windows releases'. Signed-off-by: Johannes Schindelin <[email protected]>
When tagging in a fork of `git-for-windows-automation`, we should also pull the `build-extra` and `git` repositories from the same user's (or org's) forked repositories. Signed-off-by: Johannes Schindelin <[email protected]>
On GitHub, forks of public repositories cannot be private, of course, but a fork can be created other than by clicking GitHub's `Fork` button... Signed-off-by: Johannes Schindelin <[email protected]>
For embargoed builds, we need to specify a future date that has been agreed upon with the affected stakeholders. Signed-off-by: Johannes Schindelin <[email protected]>
The release trains up to, and including, v2.48.1 still ship with i686 variants of the installer and Portable Git. We need to build the full set of i686 artifacts for those embargoed releases, too. Signed-off-by: Johannes Schindelin <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
After #131, this is the next set of patches to allow building an embargoed Git for Windows version (which is in fact the set of patches I used to prepare v2.50.1 and friends).
With these changes (that are live, in the private repository where I build them embargoed versions), the
git-for-windows-automationside of things is ready for tagging and building Git for Windows versions that use branches of the same name as the target branch of the usual PR (in a privategitrepository) from branches of the same name in (private) sibling repositoriesbuild-extra,MINGW-packages,git-sdk-64,git-sdk-arm64andgit-sdk-32. This supports building security releases from a state that is as close to the one from which the preceding version was built, so that users can upgrade from those (vulnerable) versions with minimal risk.A forked version of https://github.com/git-for-windows/gfw-helper-github-app is installed on those repositories; I will open a PR with the corresponding changes in the
gfw-helper-github-appafter this PR has been merged (plus a couple more that are [in the pipeline}(https://github.com/git-for-windows/git-for-windows-automation/compare/embargoed-builds)).