Gabriel Arazas
c2da083e5f
Similar to wrapper-manager subproject, we're just preparing to make this multi-output for our project's documentation.
1.7 KiB
title: The CI server --- = The CI server
This project makes a lot of milage from using GitHub Actions as the CI server. It uses the server for a lot of automated tasks including:
-
Checking whether all flake outputs are valid.
-
Checking if the flake lockfile is up-to-date.
-
Building the packages from this project and pushing it to a binary cache which speeds up fetching my packages.
-
Building the personalized console ISO mainly used for bootstrapping systems and publicly releasing it. [1]
-
Building the site project.
Not only this is great for them automation but also it prevents the magical it-works-on-my-machine-related problems.
Isn’t that the point of using Nix, though? To easily make reproducible builds preventing the it-works-on-my-machine problems.
Yeah but it can still happen especially that not all of the changes I push into the public repo is out.
To keep the CI workflows up-to-date, this project makes use of Dependabot which checks for GitHub actions versions weekly.
As a highlight, there are some nifty GitHub actions I found to fully take advantage of GitHub’s large ecosystem.
-
github:DeterminateSystems/update-flake-lock[Determinate Systems has a GitHub action for automating flake updates.]
-
github:DeterminateSystems/nix-installer-action[They also have a Nix installer GitHub action.]
-
github:DeterminateSystems/magic-nix-cache-action[They also have a nice GitHub action for caching Nix outputs] using your runners' built-in cache making certain steps faster.