ci: refactor workflows for release branching

[jescalada]

Closes #1517.

This refactors the release drafting and NPM publisher automation to work with release branches, as described in #1516. I've already updated #1516 with a step-by-step guide and a troubleshooting section based on my own testing.

Although it's a bit of a mess, I've replicated the release process in my git-proxy fork:

• Test releases made from drafts
• NPM test package built from those releases
• Related PRs showcasing the branching flow

[netlify]

✅ Deploy Preview for endearing-brigadeiros-63f9d0 canceled.

Name	Link
🔨 Latest commit	3ebdb71
🔍 Latest deploy log	https://app.netlify.com/projects/endearing-brigadeiros-63f9d0/deploys/6a56f8ffb7764e000866c9aa

[netlify]

✅ Deploy Preview for endearing-brigadeiros-63f9d0 canceled.

Name	Link
🔨 Latest commit	18a10be
🔍 Latest deploy log	https://app.netlify.com/projects/endearing-brigadeiros-63f9d0/deploys/69fab03283da260008d54edd

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.98%. Comparing base (096a049) to head (3ebdb71).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1520      +/-   ##
==========================================
+ Coverage   85.75%   85.98%   +0.22%     
==========================================
  Files          85       85              
  Lines        8448     8448              
  Branches     1457     1457              
==========================================
+ Hits         7245     7264      +19     
+ Misses       1172     1154      -18     
+ Partials       31       30       -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jescalada]

@kriswest Would be great to merge this in as we prepare for the 2.1 release! I've already made the release/2.0 branch from the 2.0.0 bump PR. Since these CI workflow updates haven't been merged yet, nothing has executed when making the release/2.0 branch (which is fine, since we decided to do everything manually one last time).

[kriswest]

@re-vlad could you look at this one

[re-vlad]

Renaming .github/release-drafter.yml to .github/release-drafter-config.yml breaks the release-drafter job in pr-lint.yml: the with: block (lines 58–59) does not set config-name, so the action still looks for the default .github/release-drafter.yml and will likely fail at runtime (with message: "config file not found").

[re-vlad]

The job also keeps updating a draft release on main (commitish: main), which conflicts with the GitLabFlow model where drafts are created per release/* branch by the new .github/workflows/release-drafter.yml workflow. Autolabeling is now handled by auto-label.yml (.github/workflows/auto-label.yml), so this job looks redundant.

Suggested fix: remove the release-drafter job from pr-lint.yml and add edited to auto-label.yml pull_request_target.types

[jescalada]

@re-vlad Thanks for the review! I forgot to remove the old release-drafter step from pr-lint.yml in this PR (I had already moved it into release-drafter.yml).

The point of pr-lint.yml is to just lint the PR title; and the new release-drafter.yml does exactly what the filename implies: drafting a release, rather than just being a template. The actual template/configuration is now appropriately named release-drafter-config.yml.

I think both of your comments stem from that oversight of mine.

Note that in my release tests, the updated file is being used, that's why I didn't see any related failures when making PRs or releases.

[jescalada]

@kriswest Ready for a final check!

[jescalada]

@finos/git-proxy-maintainers Just need this merged to kick off the 2.1 release 🙂

[andypols]

LGTM - but think it's a good idea to add the filter-by-commitish setting.

[andypols]

commitish controls the target branch of the generated release, but it does not by itself isolate drafts belonging to concurrent release branches

It's probably worth adding a filter-by-commitish: true. When set to true, it restricts the included commits to those that are descendants of the previous release's target_commitish (the commit or branch associated with the last release), rather than including all commits since the beginning of the repository or a fixed date.