For the past few months I've been using sourcehut's platform to work on software an it has been quite an interesting experience. Nonetheless, one of the services I really enjoy using is the their build service called builds.sr.ht.
builds.sr.ht is a service on sr.ht that allows you to submit "build manifests" for us to work on. -- man.sr.ht
The thing I don't like on GitHub Actions is that it is kind of magical. For
example, you don't actually know what it is doing when you define that an
action should only run when a specific path is modified. Not to even mention
their custom actions which usually takes a non-trivial amount of
TypeScript/JavaScript.
Contrary to this, builds.sr.ht is really explicit on its build manifest. You're basically expected to write plain shell scripts for your builds.
Reducing resource usage
As I said previously, there's no special syntax to work on specific paths, branches, pull requests and such. By default your task will run on every commit you push. In order to reduce our CI usage we can restrain our tasks to run on specific scenarios:
On path change
if ! $(git diff --quiet HEAD HEAD^ -- "<your-path>")
then
# do something
fi
On branch change
This tip was taken from issue #170.
tasks:
- check-branch: |
cd repo_name
if [ "$(git rev-parse your-branch)" != "$(git rev-parse HEAD)" ]; then \
complete-build; \
fi
NixOS on builds.sr.ht
As I don't like to write shell scripts I use Nix and this is my favorite feature
of this service. builds.sr.ht supports NixOS by default1. This means that
we can leverage Nix Flakes for truly declarative and reproducible builds there!
Let's consider a small example using Go to show you how easy it really is. A
small flake.nix containing the following content should suffice our needs:
{
inputs.nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
outputs = { self, nixpkgs, ... }:
let pkgs = import nixpkgs { system = "x86_64-linux"; };
in
{
devShells."x86_64-linux".ci = with pkgs; mkShell {
buildInputs = [ go golangci-lint ];
};
};
}
This definition is capable of giving us a shell containing Go and golangci-lint
on $PATH.
Now let's write the build manifest for our CI:
image: nixos/unstable
packages:
- nixos.nixUnstable
environment:
NIX_CONFIG: "experimental-features = nix-command flakes"
tasks:
- lint: |
cd source
nix develop .#ci -c golangci-lint run
- test: |
cd source
nix develop .#ci -c go test ./...
- build: |
cd source
nix develop .#ci -c go build
And that's it! We have our CI up and running with the guarantee of having our tools being the same on every run. No sudden updates or unexpected behavior.