feature request: add consideration for pre-release and draft releases

[jeacott1]

Hi, I'm trying to configure this project but am finding a couple of issues.

when I create github releases, they are initially drafts, they may then be updated tp pre-release and finally an actual release. I'm triggering the initial release by creating and pushing a tag with pattern v(.*) (semver).
I have "tag_resolver": "filter": { "pattern": "v(.+)"

The release-changelog-builder-action tag resolver thinks all the commits tagged with v* are releases regardless of the github release state (draft, pre-release, release). Given that this is exclusively a github-action, it would be great if there was a config that could tweak the tag resolver to ignore draft and/or pre-release releases. thoughts?

One other issue I've found is that while testing this action, I've been pushing various commits directly to main (no PR), and as a result, no changelog content unless I set commitMode: true What I think would be useful is a switch that says if changelog is empty, fallback and try with commitMode: true. I can mimic this by duplicating the action in my workflow with something like: if : ${{ steps.build_changelog.outputs.changelog =="" }} but it seems heavy handed.

[mikepenz]

Thank you for the ticket.

I am not certain I understand the first part. This action does not create releases in the sense of GitHub. It solely is tag (or ref) based and will solely generate the changelog. It has no information about wheter a tag had a draft release associated or not. What you can do is to provide toTag and fromTag manually if you want to adjust the range of what to include. As an alternative it's possible to define a filter for the tag_resolver allowing you to filter out pre releases (as long as they may follow a specific pattern like -b01, -rc01, ..

Also there is the config flag ignorePreReleases which would make it so the fromTag is tried to be resolved to a full release (Following SemVer specification)

---

To the second element. Given the specifics of this behavior this is currently outside of the scope of this action - with the commitMode itself already having significantly less functionality due to them not being proper PRs (with all additional data). Highly recommending to stricten the process for such cases (e.g. have branch protection rules to prevent direct pushes without PR and without reviewers) For that particular scenario please defer to duplicating the action in your workflow (as due to the differences for commits - you also will need a different configuration) - also it would not merge PRs and commits. As such if you have a release with both it wouldn't work either.

[jeacott1]

@mikepenz thanks for the response. I understand that this is not an action that does any releasing. - but I am trying to use it to fill the release body for generated releases.- as such I need the changelog to reflect the changes since the last release (not the last draft release).

if you consider that I might have a release history and associated tags something like this:

2.0.0 (no releases associated with this tag yet) 1.2.0 (no releases associated with this tag yet) 1.3.1 - (I want to create a draft release here) 1.2.1 (no releases associated with this tag) 1.2.0 - pre release v1.1.0 - draft release v1.0.1 - released v1.0.0 - released

I want to push a new tag of v1.3.1 at the same commit as 1.3.1 and have it trigger my release workflow. The release will be a draft initially. this action allows me to filter on only v(.*) tags, but the body of the release should be calculated from the previous final release, not the various drafts and pre-releases that may intercede. I'll maintain a complete changelog.md elsewhere but here I'm trying to capture the changes since the last actual release, so the from tag should find v1.0.1 here and give me a complete list of changes since.

essentially this feature in release-drafter https://github.com/release-drafter/release-drafter/issues/1135

re: "have branch protection rules to prevent direct pushes"

of course! - I'm just testing various configs in a sandbox, and my commit messages are actually all conventional commits, but I noticed that direct changes (and presumably PR changes where the PR title and body are empty?) don't get picked up from the commit message itself in that case.

Cheers.

[mikepenz]

I am afraid this is out of scope of this action. As mentioned - this action has no information about wether a release even exists. As this action solely depends on tags (or git refs) As this does not meet your requirements, you will need to provide to and from tag manually. Please note that this seems mostly also like a process constraint, and usually I'd advice to use pre-releases if a release is meant to be not final. or use draft releases without tags already existing.

At this time there is no plan to have this action query release information - as this seems like an edge case, in an effort to keep it maintainable.

---

This seems also process related - Don't believe this is in the scope of this action to handle (PR title and body are empty) and instead I'd encourage to embrace a stricter process and follow PR guidelines (e.g. follow title, description) rules you may have for your project. And also require PRs instead of direct commits.

[mikepenz]

Closing as this is currently not something we plan to include in this action. Thank you for the proposal.