how is changie working for you so far?

[split aspen]

I've been adopting more at $work and it's been a good experience overall, even if it's a manual step it is intentional.

One thing we recently got added in Nuke (c# equivalent to mage), was working in a monorepo:

• loop through all unreleased changes
• for each project with unreleased changes changie bump auto --project proj and changie merge and then git tag -a"$(changie latest --project proj)" -F".changes/$(changie latest --project proj) style command IF tag doesn't already exist.
• Then this means all the tags are regularly checked and it's idempotent. New tag aka release == when unrelease tag detected all prefixed.
• Else if already released, it checks that artifact registry or in your case github release also exists and resolves missing by releasing, else skipping if not.

This has been a promising process for us to use a monorepo format with multiple packages independently released, but all based on detected unreleased changes.

The negative/compromise you make with this is you don't create a release from the GUI, but require a PR with change log entry. It's been an acceptable compromise to simplify things for us I think.

Just thought I'd add that in case you have some other tricks you recently used to better manage than this.
Simplifying releases while making them intentional is a balancing act for sure.

[solar zinc]

cc @orchid jolt probably has more info here. So far I believe it's been going great.

[orchid jolt]

Overall, it's been a positive experience.

We sometimes forget to add changelog entries part of a PR, and then catch-up during the release.

When releasing, changie has everything in place for the GitHub release, which means that it's just a matter of invoking the gh CLI with the right flags, one of them being the release changelog. Pretty straightforward!

In terms of next steps, I would like us to automate more of the manual steps, and eventually get to the point where all of it can run as a single pipeline. I can definitely see us producing a few Dagger Modules part of this phase. While I don't have a clear view of the timeline for this, it's currently looking like end of Q1, more likely Q2.

So far, so good! cc @broken hare since he's been spending more time with changie in recent weeks.

All our changie commands are available in https://github.com/dagger/dagger/blob/main/RELEASING.md

[split aspen]

I created a few helpers recently that do things to trigger the changie batch auto --project/merge, trunk fmt (markdown formatter) git add and open PR with the release log updated. No need to run cli locally then. This new entry then triggers either the tagging which triggers checkout, build/release or triggers the release directly.

Another internal project we have in testing does:

• every commit to main
• check for unreleased changes
• run the changie batch/merge by looping through projects.
• check for the tag to exist and if not reconcile and add it (so it's idempotent)
• finally same thing for the published package. loop through all latest tagged versions and if the upstream release, artifact etc doesn't exist then run against to reconcile it.

I'm leaning more towards the tag being added as the final step on successful release so fixes/adjustments can be pushed and the tag represents the actual successful release of the artifact though rather than having a bunch of fix type commits in it.

If someone forgets by the way, I think the changie author had an action built that is a status check that says changelog required unless someone adds tag "changelog-not-required" or something like that.

For tagging outside of github i use mage with basically this type of command wrapped up

projectname="$(gum input --prompt 'project name in aqua: ')"
git tag -a "$(changie latest --project "${projectname}")" -F ".changes/$(changie latest --project "${projectname}").md"

That's on my solo repos, but working on making this the company standard for versioning more explicitly. We'll see. It's great for communication but not sure it will make sense on internal continual delivery projects not batched up. 🤷‍♂️

nice doc on releasing! Big fan of great contributor docs like this and do the same in my repos!

why a non annotated tag out of curosity?

if you want a little inspiration on initializing the release PR with changelog notes...
https://github.com/DelineaXPM/github-workflows/blob/main/.github/workflows/changie-trigger-release.yml

I was trying to ease maintenance after running renovate updates by generating a new build without any need to run things locally so it's a bunch of mashed together bash. Someday I'm sure this will be dagger magic ;-p