Add CI

[reivilibre]

No description provided.

[polarathene]

Hey not too sure where to ask but this PR was timed around the introduction of it.

You're using crumbtrail for the changelog management, but I don't see anything related to that in the CI so I'm assuming you're invoking it locally. I also tried a quick search for this crumbtrail project but was unsuccessful, is it a personal tool?

[reivilibre]

@polarathene

Yeah, it's a personal experimental tool at the moment, I haven't released it (yet) — partly because it's vibe coded (for now... if I like it I might take it over) and partly because it's not 'done'.

The inspiration is Towncrier. At work we use this, with changelog entries being added to changelog.d/{pr number}.{type}. It produces a nice changelog (IMO) with all the items linked to the PR that introduced them.
The problem is that you don't know the PR number until opening the PR (at least not easily) and this is fiddly and does trip people up.

I wanted a similar tool that instead uses git history for identifying which PR the changelog entries originate from, so people can just add a changelog entry using a text editor with no need to calculate the PR number (or add it after the fact)!

Not sure where your interest lies but if you'd nonetheless like a copy, I'm happy to put it up somewhere

[polarathene]

The problem is that you don't know the PR number until opening the PR (at least not easily) and this is fiddly and does trip people up.

I vaguely recall that project name when I looked into this type of thing a while ago. I didn't complete my research or get around to adopting a solution, seeing crumbtrail reminded me of that task and I was curious to learn more since I'd prefer a Rust solution.

The current project for this type of feature I have had in mind and likely will use for projects on Github with Github Actions, is 🦋 changesets, which also uses a directory with unique ID filenames (akin to your own convention, but lacking the type of change in the filename).

• They even support communicating the change across projects in a monorepo setup (example fragment)
• A useful guide reference of adding a fragment should you decide to publish your project, I think this more well established one has plenty of useful information to learn from, although it's perhaps covering a much broader scope than you anticipate with crumbtrail 😅
• It is NodeJS based (works with other languages, but expects a package.json to exist in the repo), which similar to TownCrier with Python is less than ideal personally. I'd like a Rust project, but I'm also a fan of well established/adopted and maintained projects, solo dev projects are a tad risky as the yeas go by 😓

I kind of prefer that random word approach, reminds me of of getapassphrase.com that if you look up it's source (JS on Github somewhere) it encodes a random number into a series of word sets that produces proper sentences rather than gibberish, yet with the perks of entropy (when I need to remember a secret instead of delegating solely to a password manager, I much prefer this style).

---

I wanted a similar tool that instead uses git history for identifying which PR the changelog entries originate from, so people can just add a changelog entry using a text editor with no need to calculate the PR number (or add it after the fact)!

Yeah that is ideal 👍

The changesets project works like that, but also offers a CLI for convenience of regular contributors to just generate the file names for them among other things.

I wouldn't expect the CLI usage much from third-party contributors, but for some projects especially if the CLI is in the same ecosystem like Rust I suppose it's more likely (you could also quite easily produce a minimal container image, whereas Python and NodeJS has a baseline of around 50MB or so).

For interaction with git, there is gix as a Rust native way to interact with Git.

• It's not the friendliest choice for vibe coding with in my experience (at least for something I tried no AI agent could accomplish the task back in Jan 2026, took me 2 hours manually to wade through docs and jargon to understand the low-level API calls to invoke which was approx only 10 lines...).
• Other projects like moonrepo/proto just call the git binary externally, or use libgit, those are vastly easier to integrate and LLMs are happy with that, and so will most users. I wanted a minimal binary for deploying in a container without libgit as a dep which seemed to bring in 80MB of weight IIRC for a scratch image.

---

Not sure where your interest lies but if you'd nonetheless like a copy, I'm happy to put it up somewhere

At this stage it's probably not for me 😅 I would not have the time spare to contribute, and to introduce it into projects I am involved with would require approval from other maintainers which doesn't sound likely until it's matured a bit.

I would love to see a Rust tool, but I think for many something like changesets is good enough and works, perhaps it even fits your requirements and you'll decide to focus your development time elsewhere than building a rust alternative?

[reivilibre]

Thanks for the link to changesets!
It does seem like an interesting project, but maybe too specialised on npm monorepos for my needs IMO.

I opened up the repo and clicked through to some of the intro docs and, with 'I want to manage a changelog' in mind, I don't feel it resonating with me at all — if anything it doesn't really seem to introduce the approach well.

Poking around at some of the listed example projects, I feel:

• only supporting changelog types 'major', 'minor' and 'patch' is not very useful — maybe I've just gotten too snobbish with the way we do changelogs at work but it feels like it's not writing for the right audience, to categorise changelog entries like that. (Maybe fine for libraries, but not for applications) Users usually want to know about new features, bugfixes and then separate away the internal changes.
• It seems to customise the template or to support annotations from non-GitHub, would have to write some typescript code to do that. I'm not against 'code as configuration' but it feels wrong to maintain TypeScript code of that complexity in a project that isn't involved with TypeScript regularly.
  • (Just a suspicion) This is also likely to be a packaging nightmare, so I don't expect to see this get packaged in distros easily. Ideally the tool is so minimal and easy to package that all the distros can pick it up.
• Trying to figure out some aspects of it, not super impressed with the lack of code comments e.g. https://github.com/changesets/changesets/blob/dfefc4e71fc589df92e8328e9b66e0d7ae9b4699/packages/changelog-github/src/index.ts — I find this hard to read personally. Probably just a question of maturity, but it kinda feels like a 'big project' when I wanted a 'small tool'
• as you say, needing a package.json and having the 'published on NPM' integrations expected feels wrong for a non-NPM project, but maybe this would be tolerable

I think the main point though is just that it seems the focussing on a very different use case (audience, repo style) than I want.
If it produced nice changelogs in my use case already then I could probably live with the other constraints 🤔

I do like the 'random words' idea though, might have to steal that :-) Just makes it easier to pronounce on the odd case you need to.

---

Using gix is interesting, but at the moment I just use the git CLI.
It's stable, it lightens the load of dependencies, everyone already has it (and it would potentially save distro packagers a lot of effort).
I don't think it 'should' be 80 MB, see https://pkgs.alpinelinux.org/package/edge/main/x86_64/git more like 7MB?

Installed in a fresh Alpine container, the whole installation is 25.7 MB. Can probably golf this down with distroless-type image bases. (If you know you don't need to fetch any repos using the container, you can possibly also delete the curl, zstd and other libraries involved in that...)

$ podman run -it --rm alpine:3.24
Resolved "alpine" as an alias (/home/tanuki/.cache/containers/short-name-aliases.conf)
Trying to pull docker.io/library/alpine:3.24...
Getting image source signatures
Copying blob 55afa1ecc21d done   | 
Copying config d529dd0c6e done   | 
Writing manifest to image destination
/ # apk add git
( 1/12) Installing brotli-libs (1.2.0-r1)
( 2/12) Installing c-ares (1.34.6-r0)
( 3/12) Installing libunistring (1.4.2-r0)
( 4/12) Installing libidn2 (2.3.8-r0)
( 5/12) Installing nghttp2-libs (1.69.0-r0)
( 6/12) Installing libpsl (0.21.5-r3)
( 7/12) Installing zstd-libs (1.5.7-r2)
( 8/12) Installing libcurl (8.20.0-r1)
( 9/12) Installing libexpat (2.8.1-r0)
(10/12) Installing pcre2 (10.47-r1)
(11/12) Installing git (2.54.0-r0)
(12/12) Installing git-init-template (2.54.0-r0)
Executing busybox-1.37.0-r31.trigger
OK: 20.4 MiB in 28 packages
/ # du -sh /
du: can't open '/proc/tty/driver': Permission denied
25.7M   /

Maybe you can shrink this with gix because of some hardcore link-time optimisation, but I don't know without trying it (depends which parts of gix you need or don't need for this task) and I wouldn't be confident without trying it

---

FWIW 'My' tool is now at a point where I feel it works well and does everything I need, I wasn't asking you to contribute or anything, just offering you a copy if you are curious.
It doesn't bother me either way; really I just needed something for my uses that doesn't inflict pain on anyone else and this was the best way I found so far