Infra 2576 update changelog automatically

[XxdpavelxX]

Tested here: consensys-test/metamask-extension-test-workflow2#204, https://github.com/consensys-test/metamask-extension-test-workflow2/actions/runs/18538077577
Ticket: https://consensyssoftware.atlassian.net/browse/INFRA-2576

Added a new workflow to update or create the changelog when release PRs are created or receive new merges.

Update Release Changelog PR (update-release-changelog.yml)
When it runs:
Triggers on every push to release branches matching:
Version-v* (e.g., Version-v13.3.0)
release/[0-9]+.[0-9]+.[0-9]+ (e.g., release/999.98.0)
What it does:
Calls the github-tools update-release-changelog.yml workflow
This workflow runs the update-release-changelog.sh script
The script uses @metamask/auto-changelog to generate/update the changelog

When CHANGELOG.md Gets Created or Updated
Initial Creation:
Branch Creation: When you create a release/999.98.0 branch
Auto Create Release PR: Triggers and calls create-release-pr.yml
Create Release PR: Calls github-tools to create the release PR
Changelog Creation: The github-tools script:
Creates a changelog branch: release/999.98.0-Changelog
Runs yarn auto-changelog update --rc --autoCategorize --useChangelogEntry --useShortPrLink
Creates/updates CHANGELOG.md with commits since the last tag
Creates a PR: release: release/999.98.0-Changelog
Subsequent Updates:
New Commits: When you push new commits to release/999.98.0
Update Release Changelog PR: Triggers automatically
Changelog Update: The workflow:
Checks out the existing release/999.98.0-Changelog branch
Runs the auto-changelog script again
Updates the existing CHANGELOG.md with new commits
Commits and pushes the changes to the existing changelog PR
The auto-changelog looks for git tags to determine the commit range
Duplicate Filtering: It filters out commits that don't have PR numbers or are already in the changelog

---

Note

Introduce a reusable workflow and helper script to generate/update changelog branches and draft PRs for release branches using auto-changelog.

• GitHub Actions:
  • Reusable workflow /.github/workflows/update-release-changelog.yml:
    • Accepts inputs for release-branch, platform, repository-url, and previous-version-ref; requires github-token.
    • Checks out caller repo and MetaMask/github-tools, sets up env, installs deps, and runs changelog update script with write permissions.
• Scripts:
  • Add /.github/scripts/update-release-changelog.sh to:
    • Sync release/x.y.z branch, determine release/<version>-Changelog (or fallback) branch, and checkout/create it.
    • Run auto-changelog (extension/mobile), commit updates (hotfix-aware), push branch, and create a draft PR targeting the release branch.
    • Remove commits.csv generation.

^{Written by Cursor Bugbot for commit bf1f24c. This will update automatically on new commits. Configure here.}

[gauthierpetetin]

Thanks for the PR @XxdpavelxX

There seems to be code duplication between .github/scripts/update-release-changelog.sh file and the create_changelog_pr function we have in .github/scripts/create-platform-release-pr.sh file. It would be great if both GitHub Actions were using the same code.

[gauthierpetetin]

We no longer need to support Version-v format.

[gauthierpetetin]

Do we really need to generate commits CSV file? I may be missing something, but this seems to be something that was needed back in the days when we wanted to generate the release spreadsheet.

Is is not enough to run yarn auto-changelog update command since all we want is generate the changelog?

[XxdpavelxX]

I'm not sure. I kept that behavior since it was in the .github/scripts/create-platform-release-pr.sh function for updating the changelog. But will remove it. We can always add it back in the future if we decide to. https://github.com/MetaMask/github-tools/blob/main/.github/scripts/create-platform-release-pr.sh#L397#L398

[XxdpavelxX]

I noticed this and thought about having both workflows use one script but decided that it would be better to decouple them. Here was my reasoning. Let me know what you think. @gauthierpetetin

1. I didn't want to make the logic for them be tightly coupled since making changes for one workflow could then lead to breaking the other.
2. Doing that would also complicate testing, since whenever we make a change to the script we'd have to test both workflows to make sure they still work.
3. The logic in that .github/scripts/create-platform-release-pr.sh script is already complex with 600+ lines of code. I didn't want to add more complexity which would make adding future updates and debugging more difficult.

We could add a followup cleanup task to update the old .github/scripts/create-platform-release-pr.sh to have it call the new update-release-changelog.sh script if we determine the desired behavior is the same (including removal of the csv). But I'm conflicted on whether we should do this or keep the logic for the 2 workflows separate for the reasons above.

[gauthierpetetin]

We could do it as a separate task if you prefer.

But at some point we'll need one single script to generate the changelog because both scripts do exactly the same thing.
I see the following benefits:

• If we detect an issue related to the changelog in one of the two GitHub Actions, we'll fix it for both GitHub Actions at the same time.
• It's also an occasion to refactor the code and remove legacy stuff. For example: everything related to commits.csv or the Google spreadsheet is no longer needed in both scripts.

[gauthierpetetin]

I added 2 small comment. Otherwise, looks good to me.

[gauthierpetetin]

LGTM as long as we create a separate follow-up task to eliminate code duplication between .github/scripts/update-release-changelog.sh file and .github/scripts/create-platform-release-pr.sh files.