Keep the nix branch up-to-date

[pjungkamp]

This adds a new GitHub action that keeps the nix branch up-to-date with the latest main.

The update_nix_derivation.sh script updates the version and vendorHash of the Nix derivation by checking the git tags of the repository and recalculating the vendorHash.

I'd like this to be integrated with the release process so that you can either use the nix branch for the latest build or any release tag. This would mean that the update_nix_derivation.sh script would need to be run before a release and create the appropriate commit with correct vendorHash and version. I haven't checked out how you're going about releases (apart from that you're using GoReleaser).

[pjungkamp]

As far as I can tell the Release GitHub Action makes a new release for every v* style tag. It seems that this didn't work for the v0.4.5 and v0.4.6 tags because of some build failures.

Would you mind a make_release.sh script in scripts/?

Something like:

#!/usr/bin/env bash
set -o nounset
VERSION="$1"
bash ./scripts/update_nix_derivation.sh ./nix/cunicu.nix "${VERSION}"
# create a 'ci: Update Nix derivation' commit
git tag "${VERSION}"

This would mean that a person that wants to do a release needs to have a Nix installation. But as it seems like @stv0g will be the only one tagging releases for the foreseeable future, this should be fine.

[stv0g]

Oh that’s great. Thanks @PJungkamp

I already have a script to generate GitHub releases: https://github.com/cunicu/cunicu/blob/main/scripts/sign_release.sh

The release action will only create a release draft which is not public. The shell script then goes ahead signing the release artifacts and uploads the PGP signed checksum file.

I think the easiest could be to just add a another more generic make_release.sh script which both signs the release and upgrades the Nix branch?

[pjungkamp]

I think the easiest could be to just add a another more generic make_release.sh script which both signs the release and upgrades the Nix branch?

I wanted to have the nix branch always on or right behind main, installing github:cunicu/cunicu/nix?dir=nix would then yield the latest master with an up-to-date derivation file.

Adding an update_nix_derivation.sh invocation to the sign_release.sh script would then allow us to guarantee that Nix flake outputs for github:cunicu/cunicu/<some_release_tag>?dir=nix (e.g. github:cunicu/cunicu/v0.4.6?dir=nix) are building correctly.

[stv0g]

Ah now I see your point.. I think I like this policy:

• Tagged releases have always the correct hash in the Nix derivation -> They can be directly installed with the flake ref to the respective Git tag. This is guaranteed by the Bash script (maybe also with an additional check) which I include in the scripts folder.
• The nix branch is a divergent branch following main in which the GitHub actions do this job for us.. But in essence, we will never merge back the nix into the main branch..