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!
Features:
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 cache.nixos.org/cachix)
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)
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??
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:
@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 nixbuild.net et al). But yes, nix scheduling and GHA scheduling are disconnected.
it makes me wonder if we could pull up like 50 GH actions as a build farm connected with something like tailscale Of course at that point basically anything would be cheaper, but hey - that would be a fun project if anyone is interested
Of course at that point basically anything would be cheaper, but hey - that would be a fun project if anyone is interested 
I guess less work for me