nix2container

Example of an actually-declarative container definition: https://github.com/nlewo/nix2container/blob/master/examples/... (disclosure: I have contributed to that repo)

I'm actually working on a blog article about our setup (or possibly a series of articles, depending on how much longer it gets), it'll be published on https://korz.dev once its done. In the meantime, here's the rough summary: - Go projects are built with https://github.com/nix-community/gomod2nix. We generate a list of internal packages a project depends on using `go list -json` that is then passed to gomod2nix's `buildGoApplication`. - Rust projects are built with https://github.com/cargo2nix/cargo2nix. We chose cargo2nix to get incremental builds, meaning that dependency builds can be shared between our Rust projects and that not all dependencies have to be rebuilt when adding/updating/removing dependencies from a project. - Node projects are far trickier if you want them to be able to share dependencies and depend on one another. We ha

Definitely check out nix2container— it's fundamentally oriented around asserting state on the remote container registry rather than your local store, so it not only won't push layers that already exist remotely, it won't even pull the contents necessary to assemble them, which can be a huge time savings for incremental building of these things: https://github.com/nlewo/nix2container

> The key factor behind our decision was the realization that while Docker images are industry standard, moving around 100s of megabytes of images seems unnecessarily heavy-handed when we just need to synchronize a small change. I think the culprit is more the GitHub Actions cache than Docker since it seems to be hard to get a clean cache management. I'm not sure about caching Docker image layers, but caching the Nix store with GitHub Actions is pretty complicated (not even sure it's possible): this means we have to download all required Nix store paths on each run, but i consider this is because of a GitHub Action cache limitation. So, did you consider using another CI, which offers better caching mechanisms? With a CI able to preserve the Nix store (Hydra[1] or Hercules[2] for instance), I think nix2container (author here) could also fi

FYI, the nix2container [1] project (author here) aims to speedup the standard Nix container workflow (dockerTools.buildImage) by basically skipping the tarball step: it directly streams non already pushed layers. [1] https://github.com/nlewo/nix2container

To get Rust incremental builds, did you consider using something such as crane https://github.com/ipetkov/crane ? And regarding OCI images, i built nix2container (https://github.com/nlewo/nix2container) to speed up image build and push times.