Automatic identification of target release (take Ⅱ)
GitLab 13.8 enabled the ability to avoid duplicate jobs between branch and merge request pipelines:
As a result we can safely run pipelines on merge requests without
potentially duplicating runs with branch pipelines and automatically
determine the Apertis release based on the target branch of a merge
request. For example, creating a merge request against
apertis/v2020-security should result in APERTIS_RELEASE being set to
v2020.
This removes the need to include the release identifier in the name the
source branch or manually set APERTIS_RELEASE.
Previously, due to a lacking a complete understanding of the problem, the
$CI_OPEN_MERGE_REQUESTS variable was used on it's own to try and determine
when a merge pipeline was present in addition to a branch pipeline.
However this variable is also present in merge pipelines, so a check needs
to be made to see if both $CI_OPEN_MERGE_REQUESTS and $CI_COMMIT_BRANCH is
present before blocking running of the pipeline.
On top of that, many rules relied on testing $CI_COMMIT_BRANCH, thus
causing the jobs to run in branch context rather than in the context of
the merge request.
This commit updates the rules and updates the test pipeline to reflect the change.