ci(git-artifacts): backport a couple of patches from git-sdk-64
#33
Conversation
There is no need to upload installer logs when the installer was not run ;-) Signed-off-by: Johannes Schindelin <[email protected]>
This helps debugging a lot. Signed-off-by: Johannes Schindelin <[email protected]>
When running a PowerShell script, the exit code will be determined by the last command that was run. Unfortunately, in the PR build, we run a couple of commands _after_ running the installer, and since we do not check for the exit code of the installer process, we miss failures. This is particularly bad because we missed the fact that we failed to run the 32-bit installer tests ever since we deprecated installing the 32-bit variant on a 64-bit system (such as the GitHub Actions build agent where the PR build runs...) in c800a3f60 (installer: loudly warn when installing a 32-bit Git for Windows, 2023-02-21). Let's check explictly if the installer failed. Note: We cannot simply use `$?` but need to look at the `ExitCode` attribute of the process returned by `Start-Process`, _and_ we need to pass `-PassThru` for this to work, due to a bug in `Start-Process`. See https://stackoverflow.com/a/16018287/1860823 for a more complete explanation. Signed-off-by: Johannes Schindelin <[email protected]>
In addition to the exit code, let's make extra certain that the installation succeeded. Signed-off-by: Johannes Schindelin <[email protected]>
We really want no failures to be hidden, whether fatal or non-fatal. Regular installations should always succeed without any failures. Signed-off-by: Johannes Schindelin <[email protected]>
In the new world, we cannot discern CPU architectures via BITNESS at all. Let's just align with how things are done in the `git-artifacts` GitHub workflow in git-for-windows/git-for-windows-automation. Signed-off-by: Johannes Schindelin <[email protected]>
The 'Generate bundle artifacts' step implicitly calls `add-release-note.js`, which required node.js. However, on our self-hosted Windows/ARM64 runners (the general availability of GitHub's hosted runners cannot come soon enough!), we do not install node.js. So let's use a dedicated GitHub Action to ensure that it's there when it is needed most. Signed-off-by: Johannes Schindelin <[email protected]>
|
Had to add 7954d43 and d5f2500 to actually fix the build (see https://github.com/git-for-windows/git-sdk-arm64/actions/runs/13159140512, which only fails because it could not overwrite Git for Windows' uninstaller for one reason or another). |
I just tested the artifact locally, and the installer script finished successfully. Let's assume the error in CI was either temporary or related to the self-hosted runner. IMO, let's not spend more effort on this now and have our fingers crossed that the GitHub-hosted runners will become available in the next couple weeks... |
Thank you for testing, and I agree!
In the interest of our physical health, let's not hold our breath for it, and let's expect history to repeat itself in that the date will slip again. |
It has been pushed back again, to Q2 2025 |
.
|
The
ci-artifactsworkflow is rarely exercised in git-sdk-arm64 (because of that eternally postponed general availability of the Windows/ARM64 hosted runners). As such, it is understandable that there has been a bit of bitrot in the meantime.Note: I skipped 444678c because we will never build
mingw-w64-i686-gitusing Windows/ARM64. Ever.