Add devshell/package caching #48

jaschutte · 2025-09-09T13:38:07Z

Compiles the Nix package and devshells (including HLS) for clash-cores and uploads them to the local binary cache and cachix.
These runners are hosted locally and Diepenheim and only activate on commits to the main branch. I have tested both pushing to the local binary cache and cachix.

This will cache the version of clash-compiler and clash-protocol as well, but only the ones pinned by the flake.lock. Those projects will need their own cache in-order to support different versions too.

TODO

Setup cachix token
Modify README.md to use contain a section on how to use cachix/local cache

jaschutte · 2025-09-16T16:17:39Z

I will make similar PRs to clash-protocols and for clash-compiler as well if people don't have any objections to this PR.

martijnbastiaan · 2025-09-16T18:43:23Z

I wonder how much sense it makes to advertise the local cache like this. Perhaps it should just be a company internal thing that recommends setting up the local cache. What do other people think?

jaschutte · 2025-09-17T10:03:45Z

I wonder how much sense it makes to advertise the local cache like this. Perhaps it should just be a company internal thing that recommends setting up the local cache. What do other people think?

Yeah I was wondering about that too, but I don't think there's much harm in it and it is a logical place to put the information. If there's a better place to add this information, then I'll happily put it there.

UPDATE: I moved the documentation to a small note within the ci.yml file.

Pushes the Nix build results to the locally hosted binary cache and Cachix. These will pushes will only be done commits on main. Both caches implement a garbage collector which automatically cleans packages which arent being used. Meaning that pushes on main do not waste storage.

Adds a small paragraph about using Cachix to speed up Nix-centric development.

jaschutte · 2025-10-15T17:38:22Z

Bump

Got any opinions on this @diegodiv and @DigitalBrains1 ? If not, then I'd like to merge it

martijnbastiaan · 2025-10-15T18:29:55Z

README.md

+extra-substituters = https://clash-lang.cachix.org
+extra-trusted-public-keys = clash-lang.cachix.org-1:/2N1uka38B/heaOAC+Ztd/EWLmF0RLfizWgC5tamCBg=


Isn't

nix profile install nixpkgs#cachix cachix use clash-lang

a bit less "intimidating"?

I get where you're coming from, but at the same time why make people install something when you can use Cachix just fine without having the CLI installed? Alternatively it can be listed as 'you can also do this'.

My preference would be to start out with the solution that is the simplest to perform, so cachix use clan-lang. And then make a note "It is not required to use the cachix package for this; alternatively, you can use the following configuration if you would like to avoid installing it:"

That's a funny divide here because I personally find it simpler not to install the tool at all (unless it's required somewhere else). I never used it, and always added substituters in my config files.

Well I can just remember the instructions to install and use cachix, whereas with the other instructions, I'll really need to look up the instructions or an existing deployment and copy-paste. I'm considering "simple" as "an action that is simple to perform for the user", not "my system is reduced to its simplest state".

But I'm fine with any order; I do think it makes sense to document both so people can pick what most fits their life style.

I do think it makes sense to document both so people can pick what most fits their life style.

Same!

I've included both methods now

FWIW I generally like "simple" instructions with @DigitalBrains1's definition of simple:

I'm considering "simple" as "an action that is simple to perform for the user", not "my system is reduced to its simplest state".

in READMEs. If it's a race between my desktop installing cachix and my slow ass doing a bunch of edits, I know who's going to win.

Anyway, having both is good. Just figured I'd share my POV.

Reworks the Nix paragraph to include the how to use the Cachix CLI to add the substituters.

DigitalBrains1 · 2025-10-23T14:40:59Z

.github/workflows/ci.yml

+        env:
+          ATTIC_TOKEN: ${{ secrets.ATTIC_SECRET }}
+        run: |
+          attic login --set-default public http://192.168.102.136:9200/ "$ATTIC_TOKEN"


This way, the secret shows up in the process list if you time it right. While the risk of leakage is small, it is poor form. Does attic also accept a token from stdin? Because you might be able to do

attic login --set-default public http://192.168.102.136:9200/ - <<<"$ATTIC_TOKEN"

which, as far as I know, does not leak the token via the process list. My assumption was that a - argument would be interpreted as "take it from stdin", this is pretty standard but not universal.

Ah it also seems possible without relying on bash features:

printenv ATTIC_TOKEN | attic login --set-default public http://192.168.102.136:9200/ -

Good catch! I wasn't aware that it could leak like that. Sadly it does not support reading from stdin, but we can write to ~/.config/attic/config.toml directly for the meantime.

I have written a small bash script which writes the config file and the CI invokes the bash script. Would that be leak proof?

I have also made the Cachix authentication use environment variables rather than a direct argument as well.

Related Attic PR: zhaofengli/attic#284

DigitalBrains1

Thank you for looking into avoiding the leak of secrets through the process list. I don't think we're dealing with an actual risk here, but it's nicer this way.

DigitalBrains1 · 2025-10-24T08:54:35Z

.github/workflows/ci.yml

+        env:
+          ATTIC_AUTH_TOKEN: ${{ secrets.ATTIC_SECRET }}
+        run: |
+          bash .github/scripts/attic-auth.sh


If you make the script executable and add a shebang, you can just run the script itself rather than call bash. It's more idiomatic that way.

Additionally, we have these scripts in clash-cores/.ci. Maybe once we switch to a full GitHub Actions workflow, we want to move all scripts to a subdir of .github, but currently, I'd much prefer this script to be in ~/.ci as well.

Suggested change

bash .github/scripts/attic-auth.sh

.ci/scripts/attic-auth.sh

.ci/attic-auth.sh

DigitalBrains1 · 2025-10-24T08:57:59Z

.github/scripts/attic-auth.sh

+endpoint = "http://192.168.102.136:9200"
+token = "$ATTIC_AUTH_TOKEN"
+EOF
+


This file is bracketed by blank lines; please remove leading and trailing blank lines.

Good to know! Personally like trailing blank lines but I will adapt :)

DigitalBrains1 · 2025-10-24T09:01:37Z

.github/workflows/ci.yml

+          # Having the variable be named `CACHIX_AUTH_TOKEN` authenticates cachix
+          # https://docs.cachix.org/getting-started#authenticating


It's definitely better to comment too much than comment too little! Having said that, I think this was already clear enough by calling the env var that and subsequently not referencing it directly in the run key :-).

Is it though? If I were to read it without prior context I wouldn't know that the environment variable would get picked up by the cli without being passed explicitly. Could also just be me heh

Could also just be me heh

Or it is that I have gotten used to undercommented CI concoctions 😂

It was just a bit of feedback, not a change request at all. It's fine as it is.

Reworks the authentication method to not leak the secret.

jaschutte force-pushed the automatic-push branch 2 times, most recently from 69bf9f0 to 388ad25 Compare September 15, 2025 12:29

jaschutte force-pushed the automatic-push branch 5 times, most recently from 1a56f1e to 4321391 Compare September 16, 2025 16:08

jaschutte marked this pull request as ready for review September 16, 2025 16:08

jaschutte force-pushed the automatic-push branch 2 times, most recently from 04653df to 7120300 Compare September 16, 2025 16:10

jaschutte force-pushed the automatic-push branch from 7120300 to febdb42 Compare September 17, 2025 12:27

jaschutte added 2 commits September 17, 2025 14:40

Update README.md to include Nix cache paragraph

d6d53cf

Adds a small paragraph about using Cachix to speed up Nix-centric development.

jaschutte force-pushed the automatic-push branch from febdb42 to d6d53cf Compare September 17, 2025 12:47

jaschutte requested review from DigitalBrains1 and diegodiv September 17, 2025 13:21

jaschutte mentioned this pull request Sep 19, 2025

Add automatic package pushing to binary caches clash-lang/clash-protocols#167

Open

martijnbastiaan reviewed Oct 15, 2025

View reviewed changes

martijnbastiaan approved these changes Oct 17, 2025

View reviewed changes

Update README.md to include Cachix CLI usage

b99328e

Reworks the Nix paragraph to include the how to use the Cachix CLI to add the substituters.

DigitalBrains1 reviewed Oct 23, 2025

View reviewed changes

jaschutte force-pushed the automatic-push branch 4 times, most recently from d00faf8 to e04acb3 Compare October 23, 2025 15:58

DigitalBrains1 reviewed Oct 24, 2025

View reviewed changes

Non-leaking Attic & Cachix authentication

12c100c

Reworks the authentication method to not leak the secret.

jaschutte force-pushed the automatic-push branch from e04acb3 to 12c100c Compare October 31, 2025 13:36

DigitalBrains1 approved these changes Nov 2, 2025

View reviewed changes

jaschutte merged commit 0021b39 into main Nov 3, 2025
2 checks passed

jaschutte deleted the automatic-push branch November 3, 2025 15:21

jaschutte mentioned this pull request Nov 3, 2025

Set executable bit in attic-auth.sh #51

Merged

		extra-substituters = https://clash-lang.cachix.org
		extra-trusted-public-keys = clash-lang.cachix.org-1:/2N1uka38B/heaOAC+Ztd/EWLmF0RLfizWgC5tamCBg=

		# Having the variable be named `CACHIX_AUTH_TOKEN` authenticates cachix
		# https://docs.cachix.org/getting-started#authenticating

Add devshell/package caching #48

Add devshell/package caching #48

Conversation

jaschutte commented Sep 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

TODO

Uh oh!

jaschutte commented Sep 16, 2025

Uh oh!

martijnbastiaan commented Sep 16, 2025

Uh oh!

jaschutte commented Sep 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jaschutte commented Oct 15, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jaschutte Oct 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DigitalBrains1 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jaschutte Oct 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

jaschutte commented Sep 9, 2025 •

edited

Loading

jaschutte commented Sep 17, 2025 •

edited

Loading

jaschutte Oct 21, 2025 •

edited

Loading

jaschutte Oct 31, 2025 •

edited

Loading