Conversation
| steps: | ||
| - uses: actions/checkout@v2 | ||
| - uses: nixbuild/nix-quick-install-action@v26 | ||
| - uses: cachix/cachix-action@v12 |
There was a problem hiding this comment.
I think this should probably happen in the release workflow, so that it only caches new releases
There was a problem hiding this comment.
so that nix users are only getting stable releases, not a canary/nightly build, and I think this would also cache binaries for pull requests? I guess i'm not entirely sure how the cache works
There was a problem hiding this comment.
Cachix offers a decent amount of storage space for free (10 GiB at present), but if you want that level of control, it may be a good idea to use magit-nix-cache-action for CI.
There was a problem hiding this comment.
Can you elaborate on how this saves us CI time? we are using setup-beam for the elixir/erlang installation and already cache mix dependencies
There was a problem hiding this comment.
It would save time on nix-build CI job I added in the previous PR. It's unnecessary if you don't intend to provide Nix packages from the flake. You are not using Nix to build the release assets, so the action would never accelerate your main workflow. Fro Nix, the action caches the Nix store, which saves time spent on rebuilding rebar3 with the latest Erlang every time.
dc1a34c to
f9df088
Compare
e01aed9 to
47a5547
Compare
47a5547 to
2f1859e
Compare
This PR is a follow up to #312 and is intended to:
by pushing newly built Nix assets to your cachix account.
As extra steps, you will have to:
YOUR_CACHIX_ACCOUNTwith the name of your cachix account.YOUR_CACHIX_PUBLIC_KEYwhich you can find at https://app.cachix.org/cache/YOUR_CACHIX_ACCOUNTCACHIX_AUTH_TOKENto the secrets of your repository (or even the organization).