Save cachix bandwith and your time with phoenix-ci

Hi all, this is the first release of GitHub - DevPalace/phoenix-ci. As it is right now it is definitely not yet production ready but I am sure that some of you will find it interesting!


  • Parallel Nix CI jobs execution
  • Checking if the job should be executed (usecase: don’t build OCI image if it is already in the registry)
  • Actions execution support (Like pushing an artifact or deploying applications)
  • Github Cache powered /nix/store caching (Way faster compared to pulling packages from
  • Github Cache powered Nix evaluation cache caching

Performace improvements over standard nix actions:

  • Does not build package if it is already in the binary cache
  • Builds 1 package per 1 Github runner
  • Uses Github Cache to reduce network overhead (@domenkozar will thank you for that :D)

Interesting, thank you I will certainly have a look at this. I jerry-rigged something to solve the “don’t rebuild nor download unnecessary derivations” issue, using sed and grep: “” but it’s certainly hacky, and it requires special care in the derivation that is used for testing.

1 Like

I thought that there was some sort of long-standing Nix or GitHub issue that prevented people from being able to use GitHub Action’s cache to save and restore /nix/store.

Am I misremembering / misunderstanding this? Or did you find some way to workaround the limitation here??

1 Like

I assume you are refering to /nix/store restore requiring root permissions issue. At least that’s the only issue I ran into

This is how I resolved it, not pretty but it works:


Using github cache greatly reduce the ci time, that’s so great. However, I kind of hope there’s a non-intrusive way of using github cache without deeply bundled with the whole ci framework.

Something as easy as the offical cache action way as for example:

- name: Cache Nix packages
  uses: xxx/github-nix-cache@v1

The Parallel Nix CI jobs execution stuff is great, but most existing github actions already implement their own matrix, so there’s migration cost.


Standalone /nix/store cache action is coming soon :))


For the origin story, this is a rip-off / generalization of GitHub - divnix/std-action: A GitHub Action collection for Standard originally hacked together mainly by @nrdxp who has been the original creator of the core design tenets reflected in this refactoring.

I think that attribution is warranted, according to general principles of good open source citizenship.


You definitely aren’t misremembering: feat: allow to tar files from root by blaggacao · Pull Request #1253 · actions/toolkit · GitHub

Short of being accepted, this also works around it, separately: GitHub - divnix/nix-cache-action: Cache dependencies and build outputs in GitHub Actions - forked for use with Nix

like this? :rofl:

@nrdxp I’m trying to formulate user stories / usage scenarios to help push phoenix-ci to production readiness with the motion to deprecate std-action and using phoenix-ci, instead.

Can you elaborate as concisely as possible for the interested audience on why std-action had chosen to work on drv paths instead of flake fragments (as phoenix-ci currently does)?

I’d like to understand if that is something that we want to uphold for feature parity before swapping std-action or if maybe the original motivation is superseded in some other way by phoenix-ci. If working on flake fragments is not good enough for some reason, we’d need to take care again of the .nixConfig-discovery.


The discovery phase becomes redundant somewhat if you use flake fragmants as you will have to do additional Nix evaluation, which is bad because it is hard to track that cost ahead of time. Realized drvs were used instead so that the actual task runners could begin their builds immediately without any further Nix evaluation costs.

Also, as for the cache action, I highly recommend you use nix-store --export|import instead of a generic tar invocation if you are making a custom cache action anyway, as it is much more efficient, at least in my own testing.


I guess the missing link here is that package is not a very good scheduling primitive for GitHub Actions. Instead you’d want something like Hydra where you have a queue of individual derivations; ordered by their dependency graph. However that’s gonna be annoying as a job matrix in GitHub Actions can only be like 100 in size and your average package probably pulls in more than a 100 derivations


I’m looking at GH Actions mostly as an auxiliary controle plane. It doing the work is sort of just a fallback for using a proper build farm with better scheduling (such as et al). But yes, nix scheduling and GHA scheduling are disconnected.

1 Like

it makes me wonder if we could pull up like 50 GH actions as a build farm connected with something like tailscale :smiley: Of course at that point basically anything would be cheaper, but hey - that would be a fun project if anyone is interested :wink:

1 Like

This would be a prime synthesis of collaboration: GitHub Cache storgage backend · Issue #63 · zhaofengli/attic · GitHub

For Github Actions, it seems that there is a new path:


Yep, exactly the action which I was planning to build :slight_smile: I guess less work for me :smiley:

Is that a project with possible synergies here: GitHub - nix-community/cache-nix-action: Cache Nix store in GitHub Actions to speed up workflows [maintainer=@deemp] ?

:smiley: great minds think alike!

I’ve stolen your snippet though because mine was GNU only and yours works on both BSD and GNU sed.

Now I don’t have to install GNU sed on darwin runners first; a surprisingly expensive operation on a fresh GH Actions runner.