-
Notifications
You must be signed in to change notification settings - Fork 5
Add devshell/package caching #48
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
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,80 @@ | ||
| name: CI | ||
|
|
||
| # Trigger the workflow on all pushes | ||
| on: | ||
| push: | ||
| branches: | ||
| - main | ||
|
|
||
| concurrency: | ||
| group: ${{ github.head_ref || github.run_id }} | ||
| cancel-in-progress: true | ||
|
|
||
| jobs: | ||
| packages: | ||
| name: Push package to local cache | ||
| runs-on: self-hosted | ||
| strategy: | ||
| matrix: | ||
| ghc-version: [ "ghc9101", "ghc982", "ghc964" ] | ||
| steps: | ||
| - name: Checkout | ||
| uses: actions/checkout@v4 | ||
|
|
||
| - name: Build & test | ||
| run: | | ||
| # The -L flag outputs build logs to stderr | ||
| nix build -L .#${{ matrix.ghc-version }} | ||
| - name: Push package to cache | ||
| env: | ||
| ATTIC_TOKEN: ${{ secrets.ATTIC_SECRET }} | ||
| run: | | ||
| attic login --set-default public http://192.168.102.136:9200/ "$ATTIC_TOKEN" | ||
| attic push public $(nix path-info .#${{ matrix.ghc-version }}) | ||
| - name: Push package to cachix | ||
| # if: github.ref == 'refs/heads/main' | ||
| env: | ||
| CACHIX_TOKEN: ${{ secrets.CACHIX_SECRET }} | ||
| run: | | ||
| cachix authtoken $CACHIX_TOKEN | ||
| nix path-info .#${{ matrix.ghc-version }} | cachix push clash-lang | ||
| devshells: | ||
| name: Push Nix developer shell to local cache | ||
| runs-on: self-hosted | ||
| strategy: | ||
| matrix: | ||
| ghc-version: [ "ghc9101", "ghc982", "ghc964" ] | ||
| steps: | ||
| # There's no need to configure Nix, the dockerfile handling the GHA has it done for us! | ||
| # If a dependencies are already cached, we can simply re-use them! | ||
|
|
||
| - name: Checkout | ||
| uses: actions/checkout@v4 | ||
|
|
||
| - name: Build devshell | ||
| run: | | ||
| # Since the server is x86_64-linux, we can only build the devshell | ||
| # for that | ||
| nix build .#devShells.x86_64-linux.${{ matrix.ghc-version }}-full | ||
| # Pushes the binaries to the local network | ||
| # url: http://192.168.102.136:9200/public | ||
| # public key: public:PGGlJMx1gGmU069blMqve8tS1ndzBuriUAwGBHGOo4g= | ||
| - name: Push devshell to cache | ||
| env: | ||
| ATTIC_TOKEN: ${{ secrets.ATTIC_SECRET }} | ||
| run: | | ||
| attic login --set-default public http://192.168.102.136:9200/ "$ATTIC_TOKEN" | ||
| attic push public $(nix path-info .#devShells.x86_64-linux.${{ matrix.ghc-version }}-full) | ||
| # Pushes the binaries to Cachix | ||
| - name: Push devshell to cachix | ||
| env: | ||
| CACHIX_TOKEN: ${{ secrets.CACHIX_SECRET }} | ||
| run: | | ||
| cachix authtoken $CACHIX_TOKEN | ||
| nix path-info .#devShells.x86_64-linux.${{ matrix.ghc-version }}-full | cachix push clash-lang | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -23,8 +23,37 @@ You can also look through Adam Walker's excellent list of [prebuilt Clash circui | |
| # Nix | ||
| This project exposes several Nix flake outputs. Most notably the `clash-cores` package, exposed individually or as an overlay (which you need to apply on top of clash-compiler). | ||
|
|
||
| ## Usage | ||
|
|
||
| Contributing to `clash-cores` can be done via the developer shell exposed by the Nix flake. Open a terminal and type: `nix develop`. Optionally a specific GHC version can be selected as well as a `-minimal` or `-full` version. The `-minimal` shell does **NOT** contain the Haskell Language Server, whilst the `-full` shell does. When using the developer shell, do not forget to remove the `cabal.project` file. This file contains a package source and Cabal prioritizes local package sources over Nix sources. Removing the `cabal.project` file should work fine when developing with Nix. | ||
|
|
||
| Compiling Clash and all dependencies related to it may take a long time. To remidy long compilation times, you can make use of the publically available cache on Cachix: | ||
|
|
||
| ### Cachix (binary cache) | ||
|
|
||
| Cachix contains all commits on the main branch of `clash-cores` since the cache has been setup. It is recommended to add the publically available cachix cache to your project/computer to minimize the amount of time manually compiling Clash related dependencies. | ||
|
|
||
| You can either add user-wide on your local system via `nix.conf` (usually located under `~/.config/nix`, create it if it does not exist): | ||
| ```conf | ||
| extra-substituters = https://clash-lang.cachix.org | ||
| extra-trusted-public-keys = clash-lang.cachix.org-1:/2N1uka38B/heaOAC+Ztd/EWLmF0RLfizWgC5tamCBg= | ||
|
Comment on lines
+48
to
+49
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Isn't a bit less "intimidating"?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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'.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My preference would be to start out with the solution that is the simplest to perform, so There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Well I can just remember the instructions to install and use 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Same!
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've included both methods now
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. FWIW I generally like "simple" instructions with @DigitalBrains1's definition of simple:
in READMEs. If it's a race between my desktop installing Anyway, having both is good. Just figured I'd share my POV. |
||
| ``` | ||
|
|
||
| Or as part of your `flake.nix` in your local project: | ||
| ```nix | ||
| { | ||
| nixConfig = { | ||
| extra-substituters = [ "https://clash-lang.cachix.org" ]; | ||
| extra-trusted-public-keys = [ "clash-lang.cachix.org-1:/2N1uka38B/heaOAC+Ztd/EWLmF0RLfizWgC5tamCBg=" ]; | ||
| }; | ||
| description = ...; | ||
| inputs = ...; | ||
| outputs = ...; | ||
| } | ||
| ``` | ||
|
|
||
| ## As a dependency | ||
|
|
||
| You can also add this project as a Nix-dependency. This project depends on `clash-compiler`, the recommended way to add this to your project as a Nix dependency is as follows: | ||
|
|
||
| First add `clash-compiler` and `clash-cores` to your flake inputs: | ||
|
|
||
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.
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
atticalso accept a token from stdin? Because you might be able to dowhich, 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.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.
Ah it also seems possible without relying on bash features:
printenv ATTIC_TOKEN | attic login --set-default public http://192.168.102.136:9200/ -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.
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.tomldirectly 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