`not found in this repository` when branch renamed before action runs

[jsoref]

#1572 has the same error message, but is for a more interesting case.

Here, I used github's editor to create a commit, it automatically created a patch-1. That triggered a workflow:

https://github.com/jsoref/pdns/actions/runs/4486688011

Fetching the repository /usr/bin/git -c protocol.version=2 fetch --no-tags --prune --progress --no-recurse-submodules --depth=1 origin +46056980cc77a5a76310b821f7d851913efcb51d:refs/remotes/origin/patch-1

...

ref 'refs/heads/patch-1' not found in this repository

As soon as I created the commit, I visited https://github.com/jsoref/pdns/branches and renamed the branch.

It isn't unreasonable for a flow like this to happen (I wasn't trying to break my own workflow, it's just a flow I take regularly).

Expected results: Ideally the action should be able to find the branch from the point in time when the workflow started and properly resolve things instead of from when the action itself starts running. There's nothing wrong w/ a workflow wanting to have a sarif report about a branch even if the branch is no longer...

[aibaars]

Thanks for reporting. This is an interesting corner case.

GitHub Codescanning tracks alerts per branch. For example if a new SARIF file is delivered for a branch then its contents is used to update the status of previously reported alert on the same branch. Codescanning does not use the branch name to resolve commits; when uploading you need to specify both the branch and the commit SHA.

It would be possible for Codescanning to accept SARIF reports for non-existing branches. However, I'm not sure it should. If a user specifies a wrong branch it is probably better to fail, otherwise we'd end up with a confused user that is wondering why they are not seeing any results.

[jsoref]

I think it's worth considering keeping them if the branch previously existed. Obviously if the branch never existed, that'd be a bug on the caller side.

I think for this specific case, that GitHub tracks branch renames is worth keeping in mind.

For patch-1 (or jsoref-patch-1 – both styles are used and I can't explain the logic) and similar, the runs are each going to be tangentially related, but the job run expected the link to be valid because the branch existed when it started.

[aibaars]

@adityasharad ; this sounds like it should happen only rarely. However, @jsoref mentioned to me that they run into this pretty regularly. Is there something we could do in the codeql-action to detect this case?