Skip to content

Conversation

XxdpavelxX
Copy link
Contributor

@XxdpavelxX XxdpavelxX commented Oct 14, 2025

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.

cursor[bot]

This comment was marked as outdated.

cursor[bot]

This comment was marked as outdated.

cursor[bot]

This comment was marked as outdated.

vpintorico
vpintorico previously approved these changes Oct 16, 2025
Copy link
Contributor

@gauthierpetetin gauthierpetetin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

# -----------------------------------------------------------------

# Derive the semantic version from the branch naming convention.
if [[ "${RELEASE_BRANCH}" =~ ^Version-v([0-9]+\.[0-9]+\.[0-9]+)$ ]]; then
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We no longer need to support Version-v format.

yarn --cwd install

echo "Generating test plan csv.."
yarn run gen:commits "${platform}" "${diff_base}" "${release_branch}" "${project_git_dir}"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

@XxdpavelxX XxdpavelxX Oct 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

XxdpavelxX commented Oct 17, 2025

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
Copy link
Contributor

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.

Copy link
Contributor

@gauthierpetetin gauthierpetetin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

VERSION="${BASH_REMATCH[1]}"
else
echo "Release branch '${RELEASE_BRANCH}' does not match known patterns." >&2
exit 0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cursor bot is right, we should replace with
exit 1

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unable to authenticate your request. Please make sure to connect your GitHub account to Cursor. Go to Cursor

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

shell: bash
env:
GITHUB_TOKEN: ${{ secrets.github-token }}
GH_TOKEN: ${{ secrets.github-token }}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems GH_TOKEN is not used, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I passed an extra viable. GITHUB_TOKEN is sufficient

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants