Proposal: better auth and fork handling

[zimbatm]

Problem statement

On a forked repo: GitHub Actions will run in a degraded mode because it can read from the public cache but not write to it. This is because the forked repo doesn't have access to the cachix auth token (with reason).

This becomes a problem for long forks because they must maintain an additional patch that adjusts the cachix-action name. Create a new cache, and set the CACHIX_AUTH_TOKEN to their repo.

How can this be simplified?

Idea 1 - map the token to the cache name

Since an auth token is tied to a specific cache, it can be queried to ask which cache it belongs to. That means that the name requirement can be removed. It makes the workflow more easily copy-pastable.

With that change, a forked repo could keep the same workflow and provide a different CACHIX_AUTH_TOKEN secret to their repo. No code changes are required.

The name argument becomes optional and, if provided, is merged with extraPullNames. That way, the forked repo could still use the upstream cache to minimize rebuilds.

Idea 2 - use GitHub OIDC to identify the repo to cachix

This is going to the next level :-p

With OIDC, it becomes possible to establish authentication between GitHub Actions and cachix directly. The handling of CACHIX_AUTH_TOKEN can disappear entirely. With the above change, it means that a GitHub Action now looks like this:

  - uses: cachix/install-nix-actions@vYY
  - uses: cachix/cachix-action@vXX

That's it.

You get to control on the Cachix side which repos have access to which cache, because the name of the repo is embedded in the OIDC workflow. If the relationship is missing, put a link in the error message. The user clicks the link, goes to cachix and establishes a connection (or creates a new cache).

See also: https://github.com/aws-actions/configure-aws-credentials

[domenkozar]

We'll be looking at authentication in the next months and this will be one of the things we will make sure it does well!