Closed dennisameling closed 1 year ago
Now I'm going to start the VM.
Yay!!!! So exciting indeed! 🚀
Ah... It failed because pacman
needed to be upgraded. Let me see whether I can easily fix the sync
workflow (running it manually did not work because the job was skipped).
What did not work was the GPG step. I will have to leave it at that, for now.
Oh my 😅 that commit history looks really similar to my mess from testing yesterday haha. Thank you so much for going through that! I know it can be a total pain!
Let's say if I had some time next week and wanted to kick off the build-and-deploy pipeline for arm64 to build some of the packages (git-lfs
, git-credential-manager
, etc.) for the git-sdk-arm64
, how would I go about that? I would either need:
git-for-windows-automation
(I currently can't do that, see screenshot below), so that I can at least add some initial package versions for those to git-sdk-arm64
git-sdk-arm64
.WDYT?
What did not work was the GPG step. I will have to leave it at that, for now.
Fixed in https://github.com/git-for-windows/git-for-windows-automation/pull/8 👍🏼
The fruit of all of your labor: https://wingit.blob.core.windows.net/aarch64/git-for-windows-aarch64.db
Note that this only works for self-hosted runners. GitHub Actions will pick up and use the first available arm64 runner.
Here's a successful run for
mingw-w64-openssl
onaarch64
: https://github.com/dennisameling/git-for-windows-automation/actions/runs/3735260060/jobs/6338362688. Note that I had to do some manual fixes as the pipeline assumes it has a GitHub app (GH_APP_ID
andGH_APP_PRIVATE_KEY
) at its disposal. In my run, I simply replaced that with a PAT by doingconst accessToken = ${{ secrets.DENNIS_PAT }}