Declare the merge base as base for code scanning comparisons

[cannist]

When uploading results for a pull request we tell code scanning against what other commit the results should be compared. So far we've always used the pull request base. However, when we've analyzed the merge of the feature branch and the default branch, it is much more accurate to use the head of the target branch in the comparison.

It was surprisingly difficult to determine the merge base since the default clone in actions is shallow and does not contain the merge's parents. That means the more direct approaches of getting parent data, e.g., git rev-parse HEAD^1, fail. The only way I could find was to do git show --format=raw and then parse the output.

Open question:

• Does this need a changelog entry? It is very much behind the scenes.

Merge / deployment checklist

• Confirm this change is backwards compatible with existing workflows.
• Confirm the readme has been updated if necessary.
• Confirm the changelog has been updated if necessary.

[aeisenberg]

There's also a potential conflict with #889.

[aeisenberg]

Nice trick to get the merge base.

[aeisenberg]

Do we need to change the satisfies here? Will GHES < 3.4 accept the new mergeBaseCommitOid parameter?

[cannist]

There is no new parameter on the dotcom side. This is only about computing a better value for the existing parameter base_sha in some cases. mergeBaseCommitOid is passed into the buildPayload function in this library which then selects it as the base_sha or not.

[aeisenberg]

#889 was closed. It's #902 instead that is making changes in the same general area.

[rneatherway]

LGTM. It's a shame that it's a little bit complicated to get something as simple as the first parent, especially when it's trivially available on the server side. However, I trust your judgement if you prefer to do it here. I'll leave sign-off to Andrew when he's happy.

[cannist]

I've merged in master and resolved the conflicts by running npm run build. Are we happy with this not having a changelog entry?

[aeisenberg]

I think it's fine if there is no changelog. This is an internal change.

However, I thought of something last night as I was falling asleep. The new input to specify the ref and sha for analysis will conflict here semantically. determineMergeBaseCommitOid should return undefined if the ref or sha inputs are defined.

[cannist]

However, I thought of something last night as I was falling asleep. The new input to specify the ref and sha for analysis will conflict here semantically. determineMergeBaseCommitOid should return undefined if the ref or sha inputs are defined.

Hmm, I thought that PR was closed? ... Ah, I see there was a substitute #904

I think I already have the case covered. IMO determineMergeBaseCommitOid should not act differently when these inputs are given. Its purpose is to determine the merge base when we're run in the context of a pull request. We should not use its return value when we're not uploading a result for the merge, but that decision should be made by the upload logic, not determineMergeBaseCommitOid. It is covered here.

I think there is a question of what we should declare as base when the upload ref/sha has nothing to do with the context the action is running in. Currently it will still use the previous behaviour of using the PR base. But since that has nothing to do with my change I think it might better be addressed separately.

[aeisenberg]

Thanks for the explanation. I think it all makes sense.

What is the danger of using a different merge base? Should we be adding another new input that accepts a merge base if and only if a sha and ref are specified?

[aeisenberg]

Feel free to merge after the conflict has been addressed.

[cannist]

What is the danger of using a different merge base? Should we be adding another new input that accepts a merge base if and only if a sha and ref are specified?

We're only talking about the case where the action is triggered by the pull_request event. In that case the upload sets the base_ref and base_sha parameters to tell code scanning what the results should best be compared to. Code scanning will only make use of that info if the ref looks like a PR ref, i.e. it is of the form refs/pull/N/merge or refs/pull/N/head to compute and report new and fixed alerts on the PR.

This could become a problem if the ref is set to indicate a different PR. Then using the target branch and base sha data of the PR in whose context the action is running is just wrong.
It's unlikely that you'd manually set the ref to some other PR ref, though. I do not think it makes sense to expose the base_* fields as input. We should just not populate them if the ref (and perhaps sha) deviates from the one that can be observed in the context.