Fix build-and-deploy on self-hosted ARM64 agents
#10
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
The path `${{ github.workspace }}/home` was apparently almost too long
already, with the repository name `git-for-windows-automation` repeated
_twice_ in it, and when we started using self-hosted runners whose agent
directory is called `C:\actions-runner` (as opposed to GitHub hosted
runners that have it in `D:\a`), it tipped the balance.
This matters because we want to use GNU Privacy Guard, which insists on
the full path of the `gpg-agent` socket to fit inside
`sockaddr_un.sun_path` (which only 108 bytes long). The symptom we see
is that importing GPG keys fails with a lapidary "gpg: can't connect to
the agent: IPC connect call failed".
The secret is lifted only when debugging a big further, e.g. by adding
a `gpg-agent.conf` in `$HOME/.gnupg/` with contents like this one:
debug-level guru
debug-all
log-file /tmp/gpg-agent.debug.log
Then, that log file will contain some hints like this one:
2023-01-02 20:46:25 gpg-agent[1018] listening on socket '/c/actions-runner/_work/git-for-windows-automation/git-for-windows-automation/home//.gnupg/S.gpg-agent'
2023-01-02 20:46:25 gpg-agent[1018] socket name '/c/actions-runner/_work/git-for-windows-automation/git-for-windows-automation/home//.gnupg/S.gpg-agent.extra' is too long
A similar issue was reported at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847206, but sadly the
suggested command `gpgconf --create-socketdir` fails, not only because
`/run/user/<uid>` does not exist, but even when that directory is
created, the command falls prey to the vast differences between Windows'
and Unix' permission model, and it thinks that the directory's
permissions are too lax and refuses to do its job.
So let's do the next best thing and use a home directory that is not
inside a deep path, but instead directly inside the runner's temporary
path.
Signed-off-by: Johannes Schindelin <[email protected]>
|
Here are the artifacts for verifying purposes. |
dennisameling
approved these changes
Jan 3, 2023
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.
The underlying problem why earlier attempts to deploy
mingw-w64-aarch64-git-extrafailed (e.g. this one) has nothing to do with ARM64 at all. The problem is that GNU Privacy Guard wants to put a socket into~/.gnupg/whose complete path (including NUL byte) has to fit within a mere 108 bytes.With this proposed work-around, the build succeeded (I specifically only ran the build, not the deploy part just yet, so that we can verify that the build actually worked).