Ci on Simon Shine

GitHub Releases: A poor man's Nix binary cache

Wed, 04 Nov 2026 00:56:50 +0200

tl;dr ¶

Run or install binaries without compiling them by relying on GitHub Releases as a binary cache:

$ nix run github:sshine/walltime-rs#walltime-bin -- --version
walltime 0.2.0

Motivation ¶

The simplest way to export a Rust CLI from a Nix flake is with rustPlatform.buildRustPackage.

Anyone who adds it as an input compiles it. A Rust developer or a Nix fanatic might accept a few gigabytes of build dependencies and a few more of build artifacts, plus several minutes of downloading, for a 4 MiB static binary.

Evaluating the Kubernetes-native Forgejo CI runners

Sun, 25 Oct 2026 13:19:41 +0100

Until 9 October, CI for my Forgejo ran in docker-in-docker: forgejo-runner 6.3.1 with a privileged docker:29.3.1-dind sidecar, three replicas. Since then every job runs as a Kubernetes Job, through the execution-backend protocol that forgejo-runner v13.1.0 added on 31 August.

A few people have asked what that is like to run for real. Two weeks and 54 tasks in, this is what I know. The Forgejo side of the same cluster is in Running Forgejo on a Hetzner Kubernetes cluster.

Four ways to install Nix in GitHub Actions

Wed, 21 Oct 2026 13:19:47 +0200

To run Nix in GitHub Actions, the default CI runner needs Nix installed first.

Here are some popular alternatives for pre-made CI actions that do this:

- uses: cachix/install-nix-action@v31
- uses: NixOS/nix-installer-action@v1
- uses: nixbuild/nix-quick-install-action@v35
- uses: DeterminateSystems/nix-installer-action@v23

All of these work, and do more or less the same thing. Are they all equally fast?

I’ve benchmarked each of them by first running the installer, and then running nixpkgs#hello.

# .github/workflows/install-nix-action.yml
on: workflow_dispatch

jobs:
 bench:
 runs-on: ubuntu-latest
 steps:
 - name: Install Nix
 uses: cachix/install-nix-action@v31

 - name: First build hello from pinned nixpkgs
 run: |
 nix-build --no-out-link -E 'with import (fetchTarball
 "https://github.com/NixOS/nixpkgs/archive/ac62194c3917d5f474c1a844b6fd6da2db95077d.tar.gz") {}; hello'

I didn’t specify any input parameters on them, and I didn’t add any explicit cache or permissions block.

A poor man's Nix CI cache

Wed, 21 Oct 2026 11:20:00 +0200

A thing I often come back to is speeding up CI. For almost 20 years I’ve been pushing compilation-heavy code to GitHub. Their free tier always provided enough CI minutes. So optimizing was never a resource problem, but rather a principle.

For GitHub Actions, my go-to strategy is nixbuild/nix-quick-install-action and nix-community/cache-nix-action that piggyback on the GitHub CI cache:

jobs:
 build:
 runs-on: ubuntu-latest

 steps:
 - name: Checkout
 uses: actions/checkout@d23441a48e516b6c34aea4fa41551a30e30af803 # v6.1.0, 2026-07-16

 - uses: nixbuild/nix-quick-install-action@9f63be77f412a248c9d9a65a4c82cf066cdf8f0c # v35, 2026-06-17

 - name: Restore and save Nix store
 uses: nix-community/cache-nix-action@7df957e333c1e5da7721f60227dbba6d06080569 # v7.0.2, 2026-01-30
 with:
 primary-key: nix-${{ runner.os }}-${{ hashFiles('**/*.nix', '**/flake.lock') }}
 restore-prefixes-first-match: nix-${{ runner.os }}-
 gc-max-store-size-linux: 2G
 purge: true
 purge-prefixes: nix-${{ runner.os }}-
 purge-created: 0
 purge-last-accessed: P1DT12H
 purge-primary-key: never

However, I also run a Forgejo instance with a NixOS-like CI runner that cannot benefit from these community actions.

Hashpinning

Sat, 08 Aug 2026 01:59:35 +0200

GitHub Actions workflows usually start like this:

- uses: actions/checkout@v6

v6 is a git tag that points to some commit for the release of this version of an action. There is also a v6.0.1 tag. Every time a minor or patch version is released, e.g. v6.0.2 or v6.1.0, the v6 tag is moved to that. Being unspecific means you always get the latest version that begins with v6. This is a feature.

NixOS runners on Forgejo Actions

Thu, 23 Apr 2026 22:06:40 +0200

Note: You can see the project in action here: https://git.shine.town/infra/runners

I decided to bootstrap a Kubernetes cluster with Talos and kubenix during my vacation.

A lot of experience came out of that, and I’m trying to unpack it gradually.

One of the things I host on this cluster is Forgejo, which is Codeberg’s fork of Gitea. Forgejo has Forgejo Actions which is a CI system that mimicks GitHub Actions, and it has a Container Registry much like GHCR, or DockerHub.

Speeding up CI more with Nix

Mon, 02 Feb 2026 00:44:38 +0100

Recently I wrote Speeding up CI with Nix.

I improved a 2m30s build to 1m30s after it had recently deteriorated to 10m30s.

I have another repository that would benefit from Nix.

Not because of speedups, but because it fails to install Chinese fonts properly.

My Typst résumé’s CI failed to render Chinese fonts for the longest time; for that reason, I never actually made use of the PDFs that I released. It is the fontist/setup-fontist and fontist install --formula noto_serif_cjk parts below (using 3m2s out of 3m20s):

Speeding up CI with Nix

Sun, 25 Jan 2026 12:28:38 +0100

In the article Maintaining libraries with Claude I update the CI pipeline to release the package automatically on Hackage and GitHub when pushing a version tag.

I added a git hook, check-cabal-sync.sh, that checks the version in package.yaml against the version in evm-opcodes.cabal, as well as the version in the git tag, to ensure I ran hpack before releasing; otherwise Hackage upload will fail.

Total CI running time: 2m30s before

Of which haskell-actions/setup takes: 2m5s.