search

thegeeklab / git-sv

Semantic versioning tool for git based on conventional commits
MIT License
8 stars 1 forks source link

Showcase how to create an up-to-date pending changelog #119

Open pat-s opened 2 days ago

pat-s commented 2 days ago

Not a request, just some thoughts (that could potentially be a nice addition to the README):

git sv release-notes creates the currently pending changelog for the next upcoming version.

In the current CI runs of this repo there is already a step that generates those (https://github.com/thegeeklab/git-sv/blob/647aa9cf538545142d7877c5af9015f663947063/.woodpecker/build-package.yml#L20-L25) but only publishes them on a tag event.

Arguably, a pending changelog that is somewhat visible and easy to find while at the same time unintrusive can be beneficial for certain projects. I was thinking about this coming from the plugin-release-ready-go plugin. I like that git-sv is a lot more lightweight and doesn't keep a static PR that even triggers all pull_request workflows by default.

A middle-way between a static PR and local invocation could be to have a dedicated pipeline (instead of a step) that just cats the pending release notes. I don't see an easy way to dynamically infer the link to the respective latest pipeline execution (to add this then to the README), so the README would likely need a statement like "for the pending changelog, visit the "changelog" pipeline of the most recent CI run of the main branch").

PS: very nice work overall! 👍️

xoxys commented 23 hours ago

Personally, I would use an issue e.g. something like the renovate dashboard to always show the upcoming release changelog but I dont think I would like to implement it for this repo.

pat-s commented 23 hours ago

An issue would be neat indeed. I also thought about this but had the impression that this tool wants to avoid forge-specific code/actions and aims to only interact with the local git information. Which is why I focused on the "link to the latest CI run" idea.

But yes, I also think that this would be great. It would also solve the issue of the plugin-ready-release plugin which always triggers unrelated checks for every changelog update.

xoxys commented 23 hours ago

I don't want to implement it in this repo as, indeed, the tool should stay independent of a forge. My suggestion would to use preferred CI system to update a forge issue on every commit to the default branch.