Git for Windows uses an Azure Release Pipeline to take the artifacts of a successful Git artifacts Azure Pipeline run and publish them to the various places (GitHub Releases, NuGet.org, Pacman repositories, pushing the relevant commits, etc).
This ticket is about the quest to port that Azure Release Pipeline to a GitHub workflow, which we will call release-git.yml.
This Azure Release Pipeline is the main reason why I did not start migrating to GitHub Actions sooner: It is living proof that the dream of reproducible builds that are maintained in the same revision as the corresponding source code is an illusion. Too many things outside of our control can go wrong, and when they do while we try to publish Git artifacts, it is simply no good at all to suggest to "simply patch the release workflow, commit and push" because after that commit, the revision would no longer be the one corresponding to the tag from which the artifacts were built (which takes a long time) and manually validated (which takes a long time, too).
Therefore, Git for Windows heavily depends on Azure Release Pipelines' feature where you can not only version the pipeline definition independently of the source code corresponding to the artifacts that are released; You can also edit individual stages and re-deploy just the stage, without having to re-run the entire Release Pipeline (which would not work because the GitHub Release, once published, cannot be re-published).
Sadly, this feature still has no proper equivalent in GitHub Actions world (due to above-mentioned illusion that some people seem to be unable to let go about reproducible builds and Must. Version. Workflows. Together. With. Targeted. Code).
Not even reusable workflows help in this context because it is explicitly stated that re-running a failed job will use the very same definition, from the very same SHA, as for the first run, even if the reusable workflow was specified via @<branch-name>. So if an outside change requires the release workflow to adapt (e.g. when a URL of, say, the nuget.exe tool changed and we have to adjust the workflow), we can commit and push all we want, but we cannot fix a failing workflow, we have to re-start it entirely, even if that's not possible because parts were already deployed successfully and cannot be redeployed.
These are similar to reusable workflows, but do not define entire workflow jobs, but instead steps. Just like reusable workflows, composite Actions can be specified via <org>/<repository>[/<path>][@<branch-name>]. But unlike reusable workflows, when re-running a job, the branch name is heeded. If the branch in that repository has changed, the re-run workflow will pick up that change and not insist on using the same SHA as in the first (failed) run.
So that's what we're going to do. We will create a second branch in git-for-windows-automation, probably named release, and keep it as up to date with main as possible. But we will refer to the composite Actions that implement the stages of the release-git workflow via git-for-windows/git-for-windows-automation/<stage-name>@release. That way, if we need to modify the stage due to changes outside of our control that happened since the latest successful release-git run, we can always directly push changes to the release branch and re-run the failed jobs of the release-git workflow and it will pick up the fixes and not require the entire workflow to be run again.
Git for Windows uses an Azure Release Pipeline to take the artifacts of a successful
Git artifactsAzure Pipeline run and publish them to the various places (GitHub Releases, NuGet.org, Pacman repositories, pushing the relevant commits, etc).This ticket is about the quest to port that Azure Release Pipeline to a GitHub workflow, which we will call
release-git.yml.This Azure Release Pipeline is the main reason why I did not start migrating to GitHub Actions sooner: It is living proof that the dream of reproducible builds that are maintained in the same revision as the corresponding source code is an illusion. Too many things outside of our control can go wrong, and when they do while we try to publish Git artifacts, it is simply no good at all to suggest to "simply patch the release workflow, commit and push" because after that commit, the revision would no longer be the one corresponding to the tag from which the artifacts were built (which takes a long time) and manually validated (which takes a long time, too).
Therefore, Git for Windows heavily depends on Azure Release Pipelines' feature where you can not only version the pipeline definition independently of the source code corresponding to the artifacts that are released; You can also edit individual stages and re-deploy just the stage, without having to re-run the entire Release Pipeline (which would not work because the GitHub Release, once published, cannot be re-published).
Sadly, this feature still has no proper equivalent in GitHub Actions world (due to above-mentioned illusion that some people seem to be unable to let go about reproducible builds and Must. Version. Workflows. Together. With. Targeted. Code).
Not even reusable workflows help in this context because it is explicitly stated that re-running a failed job will use the very same definition, from the very same SHA, as for the first run, even if the reusable workflow was specified via
@<branch-name>. So if an outside change requires the release workflow to adapt (e.g. when a URL of, say, thenuget.exetool changed and we have to adjust the workflow), we can commit and push all we want, but we cannot fix a failing workflow, we have to re-start it entirely, even if that's not possible because parts were already deployed successfully and cannot be redeployed.So what do we do? Composite Actions to the rescue!
These are similar to reusable workflows, but do not define entire workflow jobs, but instead steps. Just like reusable workflows, composite Actions can be specified via
<org>/<repository>[/<path>][@<branch-name>]. But unlike reusable workflows, when re-running a job, the branch name is heeded. If the branch in that repository has changed, the re-run workflow will pick up that change and not insist on using the same SHA as in the first (failed) run.So that's what we're going to do. We will create a second branch in
git-for-windows-automation, probably namedrelease, and keep it as up to date withmainas possible. But we will refer to the composite Actions that implement the stages of therelease-gitworkflow viagit-for-windows/git-for-windows-automation/<stage-name>@release. That way, if we need to modify the stage due to changes outside of our control that happened since the latest successfulrelease-gitrun, we can always directly push changes to thereleasebranch and re-run the failed jobs of therelease-gitworkflow and it will pick up the fixes and not require the entire workflow to be run again.