getLocalRef can return the wrong ref when there are multiple branches with a similar name

[raidenhasegawa]

Behavior and Cause

When you have an action triggered by a push to a certain branch, say my_branch, and another similarly named branch exists, say another/my_branch, getLocalRef will return another/my_branch instead of my_branch as it shows up first in the list of matching refs pulled by getLocalRef:

const output = (await exec('git', ['show-ref', shortName], {ignoreReturnCode: true})).stdout 
const refs = output.split(/\r?\n/g) 
                   .map(l =>; l.match(/refs\/.*$/)?.[0] ?? '')
                   .filter(l =>; l !== '')

Prefixing with this format{some_prefix}/{branch_name} causes some trouble with show-ref as they show up as refs for {branch_name}. Annoyingly, some bots will autogenerate branches with this pattern, e.g., changeset actions has a bot that does such a thing (see example below).

Example

This was caused by the changeset bot:

Comment

I'm not sure what the right solution is here, I'd be happy to work together to figure it out but I'm not an expert in actions or git in general. It does appear to be an undesirable behavior that can get by you rather silently. I think you can solve this in some cases by explicitly passing the ref in the inputs but does it make sense to fail if say there remoteRef.length > 1 in getLocalRef?

[dorny]

Hello,

Thanks for reporting the issue.
Using only fully qualified refs would be the best as it would be completely unambiguous.
However, users are used to working with short names so I implement this behavior in this action as well.
I will look into the issue and post here update as soon as I will figure out something.

[dorny]

The fix turns out to be pretty simple. I change the code so it explicitly matches what follows after refs/heads or refs/remotes/origin against the input.

Please verify if it works for you now and reopen the issue if there is still some issue.

[raidenhasegawa]

This is great, @dorny. Just ran the action with v2.10.2 and this corrected the behavior I was seeing with v2.10.1. Thanks!

[raidenhasegawa]

So this worked well for me using a short name, but it does break when I use a fully qualified ref. I think that the filter logic here breaks down when shortName is fully qualified, e.g., if shortName == 'refs/remotes/origin/{branch_name}, then match[1] == '{branch_name}' when match !== null.

I think that this can be fixed by modifying getShortName to also strip 'refs/remotes/origin' from the ref.