make CI more efficient

This MR reduces the amount of release builds that need to be done for each pipeline run. A summary of the status quo can be found here: !585 (comment 1777016175).

As of this MR, the amount of release builds done for each pipeline run are:

• 1 time for x86_64-unknown-linux-gnu to produce 2 outputs:
  • an OCI image
  • the most-commonly-used-by-NixOS-users package (self.packages.x86_64-linux.default)
• 1 time for x86_64-unknown-linux-musl to produce 2 outputs:
  • a statically-linked binary
  • a Debian package
• 1 time for aarch64-unknown-linux-musl to produce 2 outputs:
  • an OCI image
  • a statically-linked binary

These builds are now done in a single step in the pipeline, which means runs that don't have write access to the nix binary cache will rebuild less things. This helps to address the core concern raised by !585 (merged).

We could stop building x86_64-unknown-linux-gnu and produce the OCI image and NixOS package from the x86_64-unknown-linux-musl build, but there are two reasons I don't want to do this. First, making self.packages.x86_64-linux.default build an unconventional target rubs me the wrong way in general. Second, I think doing at least 1 dynamically-linked release build in CI is worth it in case it catches anything weird.

We could produce a Debian package from the aarch64-unknown-linux-musl build, but first I'd like someone to test the x86_64-unknown-linux-musl Debian package to make sure the general approach works at all.

---

• I agree to release my code and all other changes of this MR under the Apache-2.0 license

added 1 commit

• 5ed3c005 - allow overriding the attic endpoint

Compare with previous version

marked this merge request as draft

added 1 commit

• 8864c447 - wip

Compare with previous version

mentioned in merge request !585 (merged)

cargo deb complains when using the pre-built statically-linked binary:

warning: Failed to find dependency specification. (no auto deps for /builds/CobaltCause/conduit/target/debian/conduit.tmp0-stripped)

Is this a problem? I don't think our Debian package needs any dependencies anyway since it's statically linked, right?

The .gitlab-ci.yml file should also add $ATTIC_ENDPOINT as a binary cache, if it exists.

added 2 commits

• 05adeb37 - use nix-built binary to produce debian package
• 6f876094 - allow overriding the attic endpoint

Compare with previous version

added 2 commits

• 935877da - upload all devshell inputs to the cache
• 14bc81d8 - allow overriding the attic endpoint

Compare with previous version

added 2 commits

• f40d49ba - upload all devshell inputs to the cache
• 8e9ead90 - allow overriding the attic endpoint

Compare with previous version

resolved all threads

added 16 commits

• 8e9ead90...732d3318 - 7 commits from branch famedly:next
• 161ad8f9 - update to latest crane before a regression
• e70f3374 - update flake.lock
• 10b7b174 - fix documented target triple
• 4f352a71 - add trailing newline to file
• 6281c64c - upgrade nixos/nix image
• 4e09c9e5 - build all nix-based artifacts in a single job
• d5a9c6ac - use nix-built binary to produce debian package
• d411e903 - upload all devshell inputs to the cache
• ae69da63 - allow overriding the attic endpoint

Compare with previous version

resolved all threads

marked this merge request as ready

merged

mentioned in commit 20bb214d

mentioned in commit girlbossceo/conduwuit@a4ec0daa