Add option to keep unreleased changes when calling changie batch

[anGie44]

Is your feature request related to a problem? Please describe.
In cases where I want to incrementally generate a single changelog file from unreleased changes e.g. after merging a Pull Request with its own changes/unreleased/example.yml, I'm not able to do so with changie batch $(changie latest) as this will overwrite the existing file associated with changie latest instead of appending to it.

Describe the solution you'd like
In the event I have an existing changelog file in changes/, e.g. changes/v1.1.0.md which is the latest, I would like to be able to append to it with the content in changes/unreleased/ e.g. changes/unreleased/bug-fix-1.yaml such that either:

• changie batch $(changie latest) does not overwrite the existing changes/v.1.1.0md with only the unreleased content
• or a new subcommand is available to support appending e.g. changie add $(changie latest)

Describe alternatives you've considered
Only generate a single changelog file from unreleased changes in batches, i.e. just before a release

Additional context
I am running changie in Github Actions and have a closed pull_request trigger, such that after a PR is merged, i would like to append its respective changelog to the existing versioned release markdown file.

[miniscruff]

The alternative you describe is the intended method, appending to a generated changelog is not really feasible as it would require determining where exactly changes should go. And the changelogs don't have any sort of metadata on what sections relate to different kinds or the original times the changes were created. All that metadata is part of the fragment yamls.

I can help further if you need it but an append is not feasbile, sorry.

[anGie44]

Hi @miniscruff thanks so much for your feedback! And I totally understand the request was out of scope. I think what would be more feasible perhaps, and correct me if I'm wrong, would be to an optional flag to keep everything in the unreleased dir even when calling changie batch <version> so something like change batch v1.0.0 --keep. Would that be of interest to the project?

[miniscruff]

I have considered a keep flag for a little while but was never sure of any particular usage pattern that would warrant using it over slightly adjusting the process to be more inline with the changie expected workflow. Before agreeing to include this feature I would like to know more of your full workflow to see if either it can be adjusted to better line with changie or as a designated alternate use case we should promote as being supported.

I always feel weird suggesting you change your workflow but supporting many workflows would be difficult and detract from the aimed simplicity of the project.

[anGie44]

Sure thing @miniscruff, so i have two independent workflows that use changie, one that gets triggered after a PR is closed with the intention of adding the PR's changelog entry to the respective release *.md and to the main CHANGELOG.md file.
The second workflow is a bit more in line with changie such that changie is used to prepare the changelog for a minor release.

For the full implementation, the github actions files can be found at https://github.com/anGie44/terraform-provider-awscc/tree/main/.github/workflows , namely generate-changelog.yml (PR use-case) and release.yml (minor release use-case).

The workaround right now in generate-changelog.yml is to not commit the files removed when calling changie batch, which works nicely but native cli support could be more user-friendly.

[miniscruff]

Ok I think I get what is going on. After each pull request is merged, you take that changelog fragment and generate the "next" releases changelog right away. Without committing the deletions of course. You continue to do this, updating that version until you decide to run the release action. This will do the default process and you can then release.

Is the intent around generate-changelog.yml to keep the CHANGELOG updated with changes that are not yet released? You are not doing a complete release after each pull request are you? Is this like a snapshot build or just updating the repo to what will be coming? To me, updating the CHANGELOG.md and "$(changie latest).md" to look like the latest version has these changes but in reality they have not been released. Maybe there is an unreleased header here to specify but as it is generated I am not sure where this would be injected.

To be a little more general, I can see what you are doing, but I need to know why you are doing it. Sorry I should of been more clear on that with my last comment.

Also: https://github.com/anGie44/terraform-provider-awscc/blob/60f48c67f2ab712283a9c8ac54cf755f2d991078/.github/workflows/generate_changelog.yml#L28 uses changie latest which will give you the currently released latest version, this sort of implies it has been released. I believe this will do the following:

1. Release version 1.2.3
2. Create and merge a new pull request
3. generate_changelog will apply the change fragment to v1.2.3.md overriding the previous values
   Not 100% sure but it seems logically what would happen

Including a --keep would remove the git tweaks but depending on your answers above there might be more changes to accommodate your workflow.

[miniscruff]

@anGie44 I am going to move this to a discussion and create a ticket for --keep, I believe there is at least one more adjustment that could make your workflow easier but that needs more info and time, which makes more sense for a discussion.

[miniscruff]

@anGie44 v1.3.0 has the --keep option along with a few other additions.

[anGie44]

Hi @miniscruff apologies for not following up here! Thanks so much for moving forward with the discussion and making those enhancements, really appreciate it! Definitely looking forward to using it 🎉

[miniscruff]

No problem, please do take a look at the --dry-run options as it may also help your use case. Reach out for any future issues or improvement ideas you have.