Tracking issue: CI

[DanielVoogsgerd]

The current CI state seems flakely and the tooling in the Rust ecosystem has been improved tremendously. Below a list of things to fix and consider.

Fix:

• [x] Rate limit on the audit actions is often exceeded.
• [x] Remove broken tarpaulin check
• [ ] Setup cargo-deny for problem checking
• [x] Add test
• [x] Run tests on PR
• [x] Compile docs on PR (to check for failures)
• [ ] Frequently test if examples still build
• [x] Verify MSRV
• [x] Check minimal versions.
• [x] Add build check for crates that support windows

Related PR:

• 89

Other ideas are more then welcome.

[Lut99]

Great!

If I can make a few suggestions to add...

• [ ] Fix the current CI/CD code quality

  Pretty sure that the current cargo test/cargo clippy runs fail, or at least, they did for a really long time. The biggest problem was that the tests run for both macOS and Linux, and one of them/both of them failed compilation. Would be great if this could work again :)

• [ ] Add Windows target for unit tests

  For the end user tools (brane, branec, branectl I think?) we also officially support Windows, so it would be great if we can test those automatically too. Note that the Brane services themselves are in-container and therefore Unix-only. branectl perhaps too if it relies on some fundamental Unix thing (I'm OK with making that Unix-only too).

• [ ] Automatically build release binaries

  This is a lot of hassle to do manually, so doing it automatically would be perfect. We would have to build for Apple silicon too though, which will require some additional attention.

[DanielVoogsgerd]

Points added, @Lut99 could you run me through the release process. Can either be in text here or in a 1:1.

[Lut99]

It's not very hard, but a bit tedious. The deal is:

• Bump the version numbers in Cargo.toml(s) to the correct version
• Compile the required binaries
  • Compile brane for Windows, macOS, and Linux (ideally all x86/64 and ARM (64-bit), although Windows & Linux ARM are optional)
  • Compile branec for [same as brane]
  • Compile libbrane_cli (brane-cli-c) for [same as brane]
  • Compile branectl for macOS and Linux (ideally all x86/64 and ARM (64-bit), although Linux ARM is optional)
  • Compile branelet for Linux x86/64 & ARM (64-bit)
  • Compile all instance images (make.py instance) and worker instance images (make.py worker-instance) and archive them (.tar.gz)

• Rename all compiled blobs to:

  • <binary-name>[-<os>]-<arch>[.tar.gz], where:

    • <binary-name> is the monospace'd name above (plus instance and worker-instance, respectively);
    • [<os>] is either windows, darwin or linux for Windows, macOS and Linux, respectively. Omitted if only one OS is compiled (e.g., branelet and the archives)
    • <arch> is some identifier for x86/64 (x86_64) or ARM 64-bit (aarch64);
    • [.tar.gz] is the extension given for the archives.

    This naming matters because brane and branectl contain some auto-download functionality. make.py used to as well. Not sure if that's very smart, it's at least hard to debug, but that does explain why we don't zip all the binaries up :)

    See release v3.0.0 for an example.

• Finally, copy the appropriate contents from CHANGELOG.md into the issue body as description, and name the release after the version. Easy!

Obviously, some tests should also be run, although we can decide if this should be at release or commit level (or both). The ones I always run are bundled in make.py test, which has three subsections for cargo test, cargo clippy and cargo audit. But we use a few flags to make it more/less thorough.

[DanielVoogsgerd]

Okay, quite the procedure. I think it is worthwhile to automate it, hopefully it reduces the risk of missing a step, and it can also allow us to release more often, especially since we switched to feature branches.

That brings me to a semi-related question, I noticed that make.py does a cross compile for the macOS builds / windows builds. I am pretty sure using zig. Is there a reason for this?

Using CD we can just use the GitHub macOS runners to build the artifacts on the native platform. Or am I missing something here? And the same for windows of course. Different architectures should not be too much trouble as we can just compile those with a Cargo target afaik, and using cross otherwise.

Edit: Moving the CD parts to a separate tracking issue: #100