ci(release.yaml): add cross-compiled aarch64 config

[vdice]

• Adds a cross-compiled linux aarch64 entry (and add'l logic) into the GH release workflow

Approach derived from the Krustlet project.

Ref #141

Question: Do we want to update the rust.yaml action to add build/compile of this target as well? Changes would be more impactful to that file, so I wanted to ask first.

Tested release job on fork via https://github.com/vdice/wagi/actions/runs/1752378468 and resulting aarch64 binary on arm64 linux VM:

ubuntu@ip-172-31-95-42:~$ uname -a
Linux ip-172-31-95-42 #30~20.04.1-Ubuntu SMP Thu Jan 13 11:49:06 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux
ubuntu@ip-172-31-95-42:~$ ./wagi --version
WAGI Server 0.4.0

[bacongobbler]

LGTM!

[vdice]

@bacongobbler I noticed an unused field that I've removed in 4fb7dfd.

Also, I can push a commit adding the same cross-compiled aarch64 config to the rust.yaml (which runs build/test on PRs/CI) -- or would it be better to issue a follow-up?

[bacongobbler]

I noticed an unused field that I've removed in 4fb7dfd.

Good call... Looks like the --target flag is specified in the args field so everything should be fine there.

Also, I can push a commit adding the same cross-compiled aarch64 config to the rust.yaml (which runs build/test on PRs/CI) -- or would it be better to issue a follow-up?

I'd do it in the same PR IMO, however I'd let the wagi maintainers chime in here - I haven't contributed much code to this project to say whether a change like that may impact something else

[bacongobbler]

That being said I don't see how compiling to aarch64 in a PR would give the project much benefit other than verifying that it successfully compiles on different machine targets. Is that what you're looking to achieve with that change?

[vdice]

That being said I don't see how compiling to aarch64 in a PR would give the project much benefit other than verifying that it successfully compiles on different machine targets. Is that what you're looking to achieve with that change?

Right, the benefit would just be to ensure cross-compilation doesn't break on any PR, thus giving assurance that the same logic during release events should succeed as well... but, agreed, it doesn't add a lot to the existing CI that insures build/test succeeds on Linux/Mac/Windows.

[vdice]

I'll merge this as it stands, but we can revisit #147 (comment) as needed in a follow-up.