release-git: add missing aarch64 input to github-release action

[dennisameling]

In earlier commits, we added suppport for ARM64 to the release pipelines, but there's a couple more places to update. Let's do that.

[dennisameling]

@dscho I was just going through the entire chain again, and noticed that I missed this part to pass git_artifacts_aarch64_workflow_run_id to the workflow.

While adding this input, I got Invalid action input 'git_artifacts_aarch64_workflow_run_id' in VS Code. I'm pretty sure that's because line 114 uses git-for-windows/git-for-windows-automation/.github/actions/github-release@release (the release branch), which isn't up-to-date with the latest changes from the main branch yet. Is that intentional?

[dscho]

While adding this input, I got Invalid action input 'git_artifacts_aarch64_workflow_run_id' in VS Code. I'm pretty sure that's because line 114 uses git-for-windows/git-for-windows-automation/.github/actions/github-release@release (the release branch), which isn't up-to-date with the latest changes from the main branch yet. Is that intentional?

Yes, this is intentional, and the release-git workflow tries to always ensure that main and release start out identically.

0f5ecb3 explains the rationale a bit, and 060621a paints a fuller picture.

The tl;dr is: release automation is hard, and the idea is delusional that one could get it all right in a single YAML file that won't need to adapt to external changes, ever, or at least can be adapted correctly before deploying it. Instead, the need to adapt to external changes are typically detected in the middle of a release, with half the things deployed, and the rest still needing to be deployed. Using the composite Actions from a different branch allows that branch to be updated and the workflow job can then be restarted after editing just that job.

Release automation is a lot easier in Azure DevOps' original design, without YAML. You can edit failed tasks in the web browser and then re-run from there. Highly convenient. But then there was this huge push for YAML a couple of years ago, and GitHub Actions was designed with that in mind and therefore only offers YAML that must be part of the commit history, that's why we're stuck with this ugly, ugly, uggallee work-around. GitHub Actions simply lacks the support we need for complex deployments in the real world.

[dennisameling]

I also have a question about the pacman-packages job in this pipeline. It's currently designed to update the Pacman repos for x86_64 and i686 in one go, and I'm not sure whether I can simply add aarch64 to it. While please.sh quick_add already supports aarch64, I saw in the past that everything pacman-related for ARM64 runs more reliably on a native ARM64 runner, e.g. post-install scripts.

Do you think that in this case, where we would be publishing to the aarch64 pacman repo, we could get away with doing so on the existing x64 runner logic, or should I create a matrix to run the aarch64 logic on a native ARM64 runner instead?

[dscho]

I also have a question about the pacman-packages job in this pipeline. It's currently designed to update the Pacman repos for x86_64 and i686 in one go, and I'm not sure whether I can simply add aarch64 to it.

I think it should be safe.

While please.sh quick_add already supports aarch64, I saw in the past that everything pacman-related for ARM64 runs more reliably on a native ARM64 runner, e.g. post-install scripts.

That's when installing them. pacman-helper.sh quick_add does not install them.

In fact, I had tried to move the pacman-packges job to an Ubuntu runner (for speed), but it calls repo_add (actually twice), and that requires at least a part of Git for Windows' SDK.

I haven't had time to play around with it yet, but we could even consider using the custom composite init-g4w-sdk-for-pacman GitHub Action in the pacman-packages job (after adding repo_add to the sparse-checkout definition).

Do you think that in this case, where we would be publishing to the aarch64 pacman repo, we could get away with doing so on the existing x64 runner logic, or should I create a matrix to run the aarch64 logic on a native ARM64 runner instead?

I think that we can totally just add aarch64 packages in the same job, on an x86_64 runner.

[dscho]

I also have a question about the pacman-packages job in this pipeline. It's currently designed to update the Pacman repos for x86_64 and i686 in one go, and I'm not sure whether I can simply add aarch64 to it.

I think it should be safe.

Let's include this also in this here PR?