ci-package-builder: Scan/update licenses only on upstream merges
Updating the license scan artifacts on merge requests on the main branch is annoying as unrelated commits gets pushed to developers' MRs and, more importantly, it can lead to bad results in scenarios like the one below:
- commit
1234baadcafe
adds version1.1-0co1
and a MR is opened - the MR is merged on branch
apertis/v2021dev1
- commit
1234baadcafe
is tagged as1.1-0co1
, sources are stored in thepristine-lfs-source
branch and deployed - version
1.1-0co1
needs to be backported toapertis/v2020
- a MR is opened to fast-forward
apertis/v2020
to1234baadcafe
- the license scan kicks in and for any reason (for instance, newer tooling)
it detect changes in the copyright scan results, so it commits them on top
of
1234baadcafe
and pushes the5678deadbeef
commit to the MR - the MR is merged on branch
apertis/v2020
, with5678deadbeef
behind the HEAD of the branch - no tag is detected on the current branch HEAD since the actual tag is on the parent
- trying to deploy on
apertis/v2020
will then result in the CI trying to re-tag the new commit with a tag that already exists, thus failing
The right place to push the scan-license commit is when merging updates from upstream since:
- the MR is automatically generated anyway
- once contents are merged, it can operate with downstream patches applied
- the main risk the scan-license is trying to protect from is about changes in upstream licensing, and it's safe to trust Apertis developers
I've tested this on the em/systemd> repository, see the pipelines at https://gitlab.apertis.org/em/systemd/pipelines
I also based this on top of !34 (merged): even if it does strictly depend on it, avoiding the extra pipeline made more clear what was going on.
Edited by Emanuele Aina