I've been using sourcehut builds to build and deploy this blog. One of sourcehut builds' primary characteristics is simplicity, in the positive sense. The benefits of being simple are many, but in particular, I like that it is easy to projects up and running, there's not that much documentation to read, and the website is clear and snappy.
Obviously, simplicity also has its downsides, for example, it is hard to also be full-featured. In this case, it means that I have to roll up my sleeves to get something done.
The requirement I ran into was that I only want the main branch of my blog repo to be deployed to my website. Other CI services, like GitLab CI/CD and GitHub Actions, have facilities for this in their respective YAML DSLs. Sourcehut encourages you to "just" use the shell, so I cobbled together the following:
1# ... rest of .build.yml omitted ...
2tasks:
3- main-only: |
4cd unit-propagation-blog
5CURRENT_COMMIT=$(git rev-parse HEAD)
6MAIN_COMMIT=$(git show-ref --hash refs/heads/main)
7if [[ "$CURRENT_COMMIT" != "$MAIN_COMMIT" ]]
8then
9echo "Skipping build for non-main branch"
10complete-build
11fi
Simple enough: get the current checked out commit, and the commit of the main branch. Then only continue if they are equal.
The only non-standard bash function I'm using here is complete-build. This can be used to tell the sourcehut build VM that the current job is finished, and that other tasks from this job do not have to be executed. It is intentionally undocumented, so there's no guarantee this will keep working in the future. For a small side-project, I don't mind.
You might have noticed that this piece of shell code actually has a subtle problem: if you create another branch off main, the build script will actually run for that branch as well. Unless you immediately make a new commit on the new branch. I have not yet found a workaround, as sourcehut builds does not provide the actual branch name that triggered the build. My static site generator is deterministic, so the only problem here is that there might be superfluous deployments to the website. The site is still pretty lightweight, so I don't mind for now.