feat: handle release branching strategy

[alexandre-abrioux]

Hi! First of all, thank you for building this GH action. I've been using it for a while, and it works great!

I need to set it up in a project that uses the "Release Branching Strategy" (see http://releaseflow.org/).
In this flow, we have a unique branch name for every release, like so:

• release-1.0.0 --> tag 1.0.0
• release-1.1.0 --> tag 1.1.0
• etc...

To find the latest release that is not a hotfix (i.e. filter out releases created from hotfix-** branches), we would like to filter releases by testing their targets against a regex.

I've allowed myself to make this simple change that renders release-drafter compatible with this use case.
Let me know what you think. Thanks!

[jetersen]

Hi @alexandre-abrioux Do you mind resolving the conflicts? 😅

[alexandre-abrioux]

@jetersen done 🙂

[alexandre-abrioux]

Sorry, I'm closing in the end! After experimenting with it, I discovered it is not perfect, and I wouldn't recommend using it.

With a Release Branching (Release Flow) strategy, the Git history is not completely linear like with a Trunk-Based (GitHub Flow) strategy: release branches can contain cherry-picked commits and their history can diverge from the trunk. This means that to retrieve the list of commits to include in the next release draft, we cannot search commits based on the timestamp of the last commit of the previous release (like done here). By doing so, we miss commits that were introduced on the trunk after the release branch was created but before the release tag was generated. This can often happen when the time between which the release branch is created, and the release is QA'ed/tested and deployed can take multiple days.

Again, thanks for maintaining this GitHub action, as it works great with the Trunk-Based (GitHub Flow) strategy and helped me a lot in the past. I don't feel confident introducing this, as adapting it to the Release Branching (Release Flow) strategy would require a deeper refactor.

Cheers! ✌️