Resolution of MR compliance to approval_policy fails because it does not resolve scan reports on first common ancestor

Problem to solve

GitLab's doc relative to Scope of merge request approval policy comparison says “the comparison is performed against all the supported pipeline sources in the common ancestor between the source and the target branch”. After a discussion with GitLab support we've established that when the common ancestor is not one with any pipelines containing scans, and therefore no scan results exist for comparison, we end up in a case where it's not possible to determine if the license is new or not so approval is either always required or not required based on value set in fallback_behavior.

We have an issue with this - it's an understandable default but it breaks in some cases like the one here: in my company we do releases with the maven release plugin and it releases in two steps:

1. you call release:prepare, which updates the pom.xml so it contains a non-snapshot version of what you are releasing
2. you call release:perform which releases the artefacts and then sets the version in the pom.xml to next snapshot version. Each call leads to one new commit which is typically pushed directly to main during the execution of the build job (by the bot running the build whom is allowed to do that while no-one else is).

Those commies do not go through MR and they do not trigger pipeline so after each release we end up having a MR which is not properly scanned by our approval_policy, as it does not find any scan data on the target. All we're left with is choosing between always optional or always mandatory approval, which is not good: one opens for introducing a violation without any kind of hinder, the other opens for constantly blocking people by requiring a specific policy approval (by security team, whom typically aren't in the team) even if there is nothing changed at all in terms of dependencies or license compliance for example.

In our case the scan are guaranteed to have the exact same list of dependencies/licenses both before and after the release so it would be 100% safe for us to ask gitlab to consider the newest common ancestor with a scan result when approval_policy is finally triggered by a new branch/MR based change.

GitLab offers CI/CD and users can run any kind of code in jobs, which can be run an modify code without triggering new pipelines. I assume other users than those using the maven release plugin will experience the same limitation.

Proposal

Introduce a Boolean direct_common_ancestor_only flag to the policy.yml which is defaults to true and behaves like today's solution.

When sat to false the code resolving which commit is the common ancestor to use when doing the comparison should identify first common ancestor with scan data (e.g. loop through ancestors starting from direct one).

Also in addition

1. the "License compliance widget" and other "violation" widget shall explicitly list which two commits were compared
2. the security tab under pipeline shall explicitly list which two commits were compared

Intended users

Any user committing to a repo having a security policy applied to it.