Automate building nightly binaries

[luislavena]

Use crystal-xbuild container to build Ameba binaries and upload those as artifacts part of the nightly release/tag.

Currently it supports the platforms described in crystal-xbuild container:

https://github.com/luislavena/crystal-xbuild-container#supported-platforms

• Alpine Linux: x86_64 (64bits) and aarch64 (ARM64)
• macOS: aarch64 (ARM64), SDK version 13 (Ventura)

Things that remains to be confirmed and done:

• Lock to an specific version of Crystal (crystal-xbuild only provides tip/latest release)
• Enable workflow as part of successful CI on the master branch

Relates to #470

---

You can see this at work on my fork:

1. The release-nightly.yml workflow was manually triggered from here
2. The run of that workflow generated the artifacts for each of the supported platforms here
3. It forces-update the nightly tag and attach the artifacts to the release here

You can download any of the binaries and validate them locally, which I did:

$ uname -o -m
Darwin arm64

$ cd ~/repos/github.com/crystal-ameba/ameba

$ mkdir -p bin; cd bin

$ wget https://github.com/luislavena/ameba/releases/download/nightly/ameba-nightly-aarch64-apple-darwin.tar.gz

$ tar -xf ameba-nightly-aarch64-apple-darwin.tar.gz

$ cd ..

$ bin/ameba --version
1.7.0-dev

$ bin/ameba
Inspecting 304 files

................................................................................................................................................................................................................................................................................................................

Finished in 2.69 seconds
304 inspected, 0 failures

---

I've left as comments the connection between the nightly build and your current CI, as I'm not sure the best approach.

Opening this for discussion.

Cheers.
❤️ ❤️ ❤️

[veelenga]

What about using github.actor?

https://github.com/orgs/community/discussions/40405#discussioncomment-8361451

[luislavena]

According to GitHub docs, it will put the actor username and/or ID instead of just the bot as attribution for the change:

github.actor: The username of the user that triggered the initial workflow run. If the workflow run is a re-run, this value may differ from github.triggering_actor. Any workflow re-runs will use the privileges of github.actor, even if the actor initiating the re-run (github.triggering_actor) has different privileges.

github.actor_id: The account ID of the person or app that triggered the initial workflow run. For example, 1234567. Note that this is different from the actor username.

I can introduce that change, but it will show that user as the committer of the tag, instead of the bot itself: https://github.com/luislavena/ameba/releases/tag/nightly

[veelenga]

Ah, I see, thanks for the explanation. Since we need the bot name here, what do you think about using a more meaningful email address, like github-actions[bot]@users.noreply.github.com ? I see also this combination is widely used for similar use-cases:

git config --local user.name "github-actions[bot]"
git config --local user.email "41898282+github-actions[bot]@users.noreply.github.com"

[luislavena]

Thank you @veelenga, I think I found the docs reference for that:

actions/checkout#1707

I will do the updates to better display that.

[veelenga]

can the version be extracted to the env variable for easier updates?

[luislavena]

Definitely!

[luislavena]

Right now crystal-xbuild container is using tip tag, running latest version of Crystal from hydrofoil-crystal, so we should prefer to lock to an specific version.

I need to introduce a more controlled versioning on the container now that I'm actively using (and no longer just experimenting with it).

I will take care of that first before.