Skip to content

ci-package-builder: Scan/update licenses only on upstream merges

Emanuele Aina requested to merge wip/em/scan-licenses-on-upstream-merges into master

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 version 1.1-0co1 and a MR is opened
  • the MR is merged on branch apertis/v2021dev1
  • commit 1234baadcafe is tagged as 1.1-0co1, sources are stored in the pristine-lfs-source branch and deployed
  • version 1.1-0co1 needs to be backported to apertis/v2020
  • a MR is opened to fast-forward apertis/v2020 to 1234baadcafe
  • 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 the 5678deadbeef commit to the MR
  • the MR is merged on branch apertis/v2020, with 5678deadbeef 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

Merge request reports