Skip to content

make CI more efficient

Charles Hall requested to merge CobaltCause/conduit:ci-efficiency into next

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

Merge request reports

Loading