-
-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ci: add cachix-action #319
Conversation
@@ -128,4 +128,8 @@ jobs: | |||
steps: | |||
- uses: actions/checkout@v2 | |||
- uses: nixbuild/nix-quick-install-action@v26 | |||
- uses: cachix/cachix-action@v12 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should probably happen in the release workflow, so that it only caches new releases
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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_ACCOUNT
with the name of your cachix account.YOUR_CACHIX_PUBLIC_KEY
which you can find at https://app.cachix.org/cache/YOUR_CACHIX_ACCOUNTCACHIX_AUTH_TOKEN
to the secrets of your repository (or even the organization).