Changelog proof of concept

[justinrubek]

This is an attempt to add an automated CHANGELOG.md using conventional commits. This also represents a point in time that a few decisions need to be made. Specifically: this implementation leans more more heavily on nix than just provided a devshell and some packages. For the most part it isn't locking us down to nix, but using it makes it a lot more simple to manage and reason though. I will also discuss a caveat to this and what can be done.

tooling

• cocogitto - this generates the changelog, validates commit messages, and handles tagging/commiting changes
• bomper - updates hardcoded strings in files (Cargo.toml, Cargo.lock, some nix). disclaimer: this is a tool I wrote specifically for this purpose. I haven't found a better one out there but would love it one was found

configuration

This adds two GitHub Actions jobs. One can call cog bump, push the updated code, and create a GitHub release with the changelog. The other can verify that all commits are valid conventional commits (and runs on PR). To assist in this a number of scripts have been defined in the nix devshell. These are all added to PATH in the devshell and are available. The actions use nix develop -c "command" to invoke a single command at a time. I haven't tested the actions (since they need to be on GitHub to run) but the individual scripts they call do seem to work as expected.

When cog bump is called, it executes bomper to update hardcoded strings at the same time (see cog.toml and bomp.toml), which will keep the versions properly up to date. If this is misconfigured the operation will fail.

caveats

Since this uses nix for CI it will have to build all of the dependencies when needed. During local development this isn't a huge problem because the derivations will quickly be cached. In GitHub actions though, it will not be persisted without a self-hosted runner. While it may be possible to come up with a cache action for these dependencies, there does not seem to be any publicly available good solutions. That is, except a subscription to cachix's starter tier and the cachix-action. I have experience working with it and the set up is very simple and dramatically reduces the time needed. Another benefit is that it can be included on developer machines and can share the same cache. Alternatively a self-hosted runner would probably work, although I've never tried that with nix.

TODO

• call the release action. currently it is only configured to run on workflow_dispatch

[justinrubek]

Closing this until something is decided. If we pickup a solution to cache nix derivations then I will resume work on this using this branch as a guide