INFRA-2867-Fix workflow inputs to allow branch name

[XxdpavelxX]

Ticket: https://consensyssoftware.atlassian.net/browse/INFRA-2867

The Github Action is supposed to accept 3 kind of references as inputs: branch name, tag, commit hash. However, it doesn’t work with branch names. To fix this, we should check the format of the references passed to filterCommitsByTeam function in github-tools repo, detect if the reference is a branch name, and if so, prefix it with origin/. Otherwise the Github Action can’t find the branch. Additionally we should check if the branch exists before calling filterCommitsByTeam function (or at the beginning of the function) and throw appropriate error message if it doesn’t.

This PR adds branch name as a possible input for Previous release version reference in Create Release Pull Request Workflow

Tested here: https://github.com/consensys-test/metamask-extension-test-workflow2/actions/runs/17220284141/job/48854743844

[gauthierpetetin]

Thank you for this PR @XxdpavelxX!

I find the code a bit difficult to follow, mainly because of some variable names. Not necessarily the ones you introduced, but some that were already in use and don’t clearly reflect what the variables represent.
Would you be open to doing a few renamings as part of this PR?

• previous-version-tag to be renamed previous-version-ref, as it can be a branch name, a tag, or a commit hash (not only a tag)
• PREVIOUS_VERSION to be renamed PREVIOUS_VERSION_REF, for the same reason
• previous_version to be renamed previous_version_ref, for the same reason
• branchA to be renamed refA, for the same reason
• branchB to be renamed refB, for the same reason

Also, still in terms of variable naming, what is DIFF_BASE for?

In terms of logging, I see you log something when the previous_version_ref is recognized to be a branch name:

echo "Detected remote branch for previous version: ${previous_version}"

Could we also log something when it's not the case? Such as:

echo "No remote branch detected for previous version: ${previous_version}"

Finally, I think it would be helpful to comment the code with a few sentences explaining why we need this change, why we need it only when the reference is a branch name, what happened in the git log function without these changes, etc.

[XxdpavelxX]

Thank you for this PR @XxdpavelxX!

I find the code a bit difficult to follow, mainly because of some variable names. Not necessarily the ones you introduced, but some that were already in use and don’t clearly reflect what the variables represent. Would you be open to doing a few renamings as part of this PR?

• previous-version-tag to be renamed previous-version-ref, as it can be a branch name, a tag, or a commit hash (not only a tag)
• PREVIOUS_VERSION to be renamed PREVIOUS_VERSION_REF, for the same reason
• previous_version to be renamed previous_version_ref, for the same reason
• branchA to be renamed refA, for the same reason
• branchB to be renamed refB, for the same reason

Also, still in terms of variable naming, what is DIFF_BASE for?

In terms of logging, I see you log something when the previous_version_ref is recognized to be a branch name:

echo "Detected remote branch for previous version: ${previous_version}"

Could we also log something when it's not the case? Such as:

echo "No remote branch detected for previous version: ${previous_version}"

Finally, I think it would be helpful to comment the code with a few sentences explaining why we need this change, why we need it only when the reference is a branch name, what happened in the git log function without these changes, etc.

Fixes made. Also DIFF_BASE is the “base” git ref used for the left side of the diff when collecting commits to put in commits.csv (the right side being release_branch). It’s the git ref to compare against when listing commits for the release. If that’s a branch name, it’s resolved to origin/; if it’s a tag or SHA, it’s used as-is.

[gauthierpetetin]

Hi @XxdpavelxX , almost looks good to me. I made a few last suggestions, mainly to comment the code.

[gauthierpetetin]

LGTM

We'll have to import these changes in Extension and Mobile repos. While doing so, we'll have to think of renaming previous-version-tag into previous-version-ref, as it's a breaking change.