Filter by range (semver)

Checklist

• I have searched for similar PRs
  • None
• I have searched for similar issues
  • Related discussions I found were in all of :Question - Hotfix vs actual develop branch #520Branch specific configuration? #656Release notes for release branches #844[Question] Draft releases for release branches #1411
• Added & ran tests
• Joi-validated input (through config yaml only - action inputs are not validated somehow ?)
• Documentation

Content

👉 Filter releases that satisfies a semver range.

When looking for previous releases in the repository,release-drafter currently offers two filtering options :

• filter-by-commitish
  • consider releases that have a particulartarget-commitish (ex:main orrefs/heads/main)
• tag-prefix
  • consider releases that have a particular prefix in theirtag-name (ex:sub-package/*)
  • more than a filter : also strips the prefix when parsing and computing versions for the upcoming tag

✨ This pull request adds another filter :

• filter-by-range
  • consider releases based on theirtag-name, which should satisfy a given semver range

How does it work

When deciding whether to update an existing release or creating a new one, thefindReleases function oflib/releases.js is responsible for returning the latest release as well as a potentially already-existing one (drafted).

This is done by :

1. fetching every existing releases
2. filtering those we want to consider for the currentrelease-drafter run
3. Finding-out which are draft-releases, and which is the latest.

This PR introduces a new filter in step 2. :

releases.filter((r)=>{constparsedRange=semver.validRange(filterByRange)// Already validated in schema.jsconstparsedVersion=semver.coerce(r.tag_name).version// coerce() strips prefixesreturnsemver.satisfies(parsedVersion,parsedRange)})

Motivations

My use-case is to be able to implement strictTrunk Based Development, in particular the proposal aboutrelease branches.

When publishing a release on themain branch (thetrunk), for instancev1.2.0. The target-commitish would bemain (orrefs/heads/main, ormaster etc...).

Based-off that tag, arelease/v1.2 branch would be created, such as hotfixes for that particular produciton release might be easily pushed and deployed. A hotfix-deployment would be triggerd through another published release on the release-branch (ex:v1.2.1), with a target-commitish ofrelease/v1.2.

Since we want every release to be drafted before-hand, an automation such asrealease-drafter comes very handy ! However, it currently cannot create draft-releases for bothmain andrelease/vx.x branchessimultaneously. Filtering withfilter-by-commitish fails to retrievev1.2.0 onmain when drafting forv1.2.1 onrelease/v1.2.

Using this PR's feature, one would just have to specifyfilter-by-range: ~1.2.0 on draft-releases for hotfixes (on the 1.2 release branch).

For releases to contain relevant informations in the context ofTrunk Based Development,release-drafter should also be able to add individual commits it's release body. (see#1409) This is because the method encourages devs to all work on the same branch, especially for hotfixes onrelease/ branches.

A simple empty draft (when no PR were pushed), however, is already a big leap towardsrelease-drafter being usable with release branches.

Example

Input is :filter-by-range: ~1.1.0

Release drafter correctly identifies I want to publish a hotfix onrelease/v1.1 by filtering out whatever is not in the~1.1.0 range (1.2.x,1.0.x and0.0.x etc...).

It correctly identifiesv1.1.2 as thelatest release, and published a new draft (forv1.1.3 mot likely), even though a draft might already exist for the upcomingv2.1.0 release.

my-repo/test: Found 14 releases##[debug]Parsing raw range "~1.1.0" as ">=1.1.0 <1.2.0-0"##[debug]Range ">=1.1.0 <1.2.0-0" does not satisfy version "2.0.0"##[debug]Range ">=1.1.0 <1.2.0-0" does not satisfy version "1.2.1"##[debug]Range ">=1.1.0 <1.2.0-0" does not satisfy version "1.2.0" ##[debug]Range ">=1.1.0 <1.2.0-0" satisfies version "1.1.2" ##[debug]Range ">=1.1.0 <1.2.0-0" satisfies version "1.1.1" ##[debug]Range ">=1.1.0 <1.2.0-0" satisfies version "1.1.0" ##[debug]Range ">=1.1.0 <1.2.0-0" does not satisfy version "1.0.0" ##[debug]Range ">=1.1.0 <1.2.0-0" does not satisfy version "0.6.0" ##[debug]Range ">=1.1.0 <1.2.0-0" does not satisfy version "0.5.0" ##[debug]Range ">=1.1.0 <1.2.0-0" does not satisfy version "0.4.0" ##[debug]Range ">=1.1.0 <1.2.0-0" does not satisfy version "0.3.0" ##[debug]Range ">=1.1.0 <1.2.0-0" does not satisfy version "0.2.1" ##[debug]Range ">=1.1.0 <1.2.0-0" does not satisfy version "0.2.0" ##[debug]Range ">=1.1.0 <1.2.0-0" does not satisfy version "0.1.0" my-repo/test: No draft release foundmy-repo/test: Last release: v1.1.2

Integrating the whole thing in your trunk-based repo is as simple as :

# .github/workflows/release-drafter.hotfix.ymlname:Draft a release for hotfix (release/** branches)on:push:branches:      -"release/**"# ...steps:      -name:Get current tag# For release/v2.9.0, outputs number=2.9.0id:tagrun:|          branch_name="${{ github.ref_name }}"          tag_number="${branch_name/release\/v/""}"          echo "number=$tag_number" >> $GITHUB_OUTPUT          -name:Release drafteruses:cchanche/release-drafter@f72495a3e1d4b4bae78779e99a84052334b6654bwith:filter-by-range:~${{ steps.tag.outputs.number }}# "~2.9.0" translates to ">=2.9.0 <2.10.0-0"commitish:${{ github.ref_name }}

commitish: ${{ github.ref_name }} was added for clarity, but is not needed since the workflow already runs on the correspondingrelease/** branch.