1. 18 Oct, 2021 1 commit
    • Emanuele Aina's avatar
      merge-updates: Set $REBASE_RANGE to rebase changes instead of merging · 1fdcdbca
      Emanuele Aina authored
      When downstreams need to mirror our packaging repositories they need to
      pull the latest but also preserve the downstream changes they
      For instance assume that a downstream has a `downstream/v2021` branch
      that is based on `apertis/v2021-updates` (based on Buster) plus some
      customization and needs to mirror `apertis/v2022dev3` (based on
      Bullseye) while preserving the customization.
      Naively doing a merge would hit conflicts since the
      `apertis/v2021-updates` has diverged from the point where
      `apertis/v2022dev3` has been branched, and the Buster updates would not
      apply on the Bullseye-based branch.
      The most sensible option is to rebase the changes: if there are no
      downstream changes (the most common case) this becomes a no-op and the
      process can proceed easily, otherwise it still has a good chance to be
      able to apply simple customizations.
      Use the newly introduced `--rebase-range` flag only when explicitly told
      to do so. During mirroring, the orchestrating job will ensure that the
      `$REBASE_RANGE` variable is set for the pipelines triggered on each
      packaging repository.
      Signed-off-by: Emanuele Aina's avatarEmanuele Aina <emanuele.aina@collabora.com>
  2. 06 Oct, 2021 2 commits
  3. 30 Sep, 2021 1 commit
    • Emanuele Aina's avatar
      Prevent duplicated versions from being landed · 74534c48
      Emanuele Aina authored
      Sometimes branches diverge and it's not obvious that we're about to
      create a new release with an already-used version.
      The release pipeline would then fail after the changes have been landed,
      when it tries to create an already existing tag.
      To catch the issue more timely, we can check if a tag matching the
      current to-be-released version already exists and complain before the
      changes get landed.
      Signed-off-by: Emanuele Aina's avatarEmanuele Aina <emanuele.aina@collabora.com>
  4. 23 Sep, 2021 1 commit
  5. 22 Sep, 2021 1 commit
    • Dylan Aïssi's avatar
      Fix another variant of "invalid variable name" · 49b7991a
      Dylan Aïssi authored
      This time, when running the pipeline on branches like "debian/buster-proposed-updates" it fails
      to find on which downstream branch the updates should be merged, hitting a
      "invalid variable name" error.
      To fix that, strip the suffix from the upstream release so that when running
      on `debian/buster-proposed-updates` we look for the downstreams of `debian/buster`.
      Signed-off-by: Dylan Aïssi's avatarDylan Aïssi <dylan.aissi@collabora.com>
  6. 20 Sep, 2021 1 commit
  7. 16 Sep, 2021 1 commit
  8. 15 Sep, 2021 1 commit
  9. 31 Aug, 2021 3 commits
    • Frederic Danis's avatar
      Fix get build log offset · 09885bb7
      Frederic Danis authored
      build.log file size test fails due to ${OFFSET} replace by nothing.
      `$` of OFFSET variable substitution should be escaped to be used in the
      resulting job script, instead of being replaced by nothing during job
      We can't use multiplier suffix for MAX_BUILDLOG_SIZE as it is used in
      arithmetic substitution.
      Signed-off-by: Frederic Danis's avatarFrédéric Danis <frederic.danis@collabora.com>
    • Frederic Danis's avatar
      Add link to build.log · 2c99d37b
      Frederic Danis authored
      Signed-off-by: Frederic Danis's avatarFrédéric Danis <frederic.danis@collabora.com>
    • Frederic Danis's avatar
      Improve build log display · 36015b92
      Frederic Danis authored
      GitLab at most collect 4 megabytes of log output to show as part of the
      "live" job view. For failed jobs generating more log, the last log lines
      are only available in the artifacts, and not displayed in the "live" job
      The remote build log can be retrieved in 2 times, saving and displaying
      the logs in the "live" job view up to MAX_BUILDLOG_SIZE bytes, and if the
      logs are bigger saving them and displaying the last END_BUILDLOG_SIZE bytes
      of the build log at the end.
      Signed-off-by: Frederic Danis's avatarFrédéric Danis <frederic.danis@collabora.com>
  10. 17 Aug, 2021 1 commit
    • Frederic Danis's avatar
      Fix SECTION name · 0ec2990b
      Frederic Danis authored
      When the git commit branch use multiple `/`, the PROJECT can get an
      incorrect path for OBS.
      This is fixed by replacing CI_COMMIT_REF_NAME by CI_COMMIT_REF_SLUG, which
      already replace everything except 0-9 and a-z replaced by -, then replace
      all `-` with `:`.
      Signed-off-by: Frederic Danis's avatarFrédéric Danis <frederic.danis@collabora.com>
  11. 16 Aug, 2021 3 commits
  12. 01 Aug, 2021 1 commit
    • Emanuele Aina's avatar
      Do not run lintian on release too · 492a0006
      Emanuele Aina authored
      Since 284d3236
       we no longer run lintian on the built source packages
      during the test build, but we forgot to disable it during the release
      build step. This still causes big packages like firefox-esr to time out
      after the job has been running for an hour (or worse, go out-of-memory).
      Avoid the issue by disabling lintian in the same way on both places.
      Signed-off-by: Emanuele Aina's avatarEmanuele Aina <emanuele.aina@collabora.com>
  13. 30 Jul, 2021 1 commit
  14. 26 Jul, 2021 1 commit
    • Emanuele Aina's avatar
      Do not run lintian on the built source packages · 284d3236
      Emanuele Aina authored
      The vast majority of our packages is imported from Debian and we're not
      going to act on any report from Lintian about them any time soon.
      Some large packages like `firefox-esr` even fail to build due to it,
      since lintian makes them exceed the 1h timeout.
      Let's then avoid wasting precious CI time by avoiding lintian.
      For the packages where running lintian is desired, that is the
      Apertis-specific packages, set up a post-build custom local pipeline
      to execute it.
      Signed-off-by: Emanuele Aina's avatarEmanuele Aina <emanuele.aina@collabora.com>
  15. 24 Jul, 2021 1 commit
  16. 20 Jul, 2021 1 commit
  17. 19 Jul, 2021 1 commit
  18. 14 Jul, 2021 1 commit
    • Emanuele Aina's avatar
      Run updates on debian/*-{security,updates} branches as well · 211887b6
      Emanuele Aina authored
      Allow to trigger the update pipeline on branches like
      `debian/buster-security`, not just `debian/buster`. This should handle
      corner cases where a package got imported from buster-security and lacks
      a `debian/buster` branch.
      The `apertis-pkg-pull-updates` script always looks at all the related
      suites at the same time, so triggering the update on either branches
      should produce the same results.
      Signed-off-by: Emanuele Aina's avatarEmanuele Aina <emanuele.aina@collabora.com>
  19. 01 Jul, 2021 1 commit
  20. 28 Jun, 2021 4 commits
  21. 18 Jun, 2021 1 commit
  22. 04 Jun, 2021 1 commit
  23. 20 May, 2021 3 commits
  24. 17 May, 2021 1 commit
    • Emanuele Aina's avatar
      merge-updates: Change downstream packaging suffix to `+apertisX` · 2f841b92
      Emanuele Aina authored
      We moved from `coX` to `apertisX` as the packaging suffix but
      unfortunately it turned out to interact badly with the build suffix on
      OBS in some scenarios:
      1. `bluez` in Debian has the `5.55-3` version
      2. it gets uploaded to OBS with no changes, forgetting to add the
         `apertisX` suffix
      3. OBS appends the build suffix, generating binaries with version
      4. we update `bluez` appending the `apertisX` suffix, yielding
      5. OBS appends the build suffix, generating binaries with version
      6. reprepro gets the new binaries from OBS but the ordering is now wrong
         since `5.55-3apertis1bv2022dev2b1` < `5.55-3bv2022dev2b1` and will
         refuse to publish the newly built binaries
      Switching to `+apertisX` has the following advantages:
      * it can be rolled out progressively using the standard workflow
      * no need to change the build suffix
        * no need to rebuild everything on OBS
        * no need to manually delete entries from reprepro
      * backports work correctly, `+apertisX` sorts newer than `coX` and
        the OBS suffixes
      * mixing releases like v2021 and v2022 should not produce surprising
        effects like v2021 builds sorting newer than v2022
      The drawbacks are:
      * every non-Apertis-specific package needs to be tweaked
      * if Debian package maintainer releases a new version by appending a
        suffix there are higher chances that the `+apertisX` suffix will sort
        newer (we already have this issue, but this increases the chances to
        hit it)
      Signed-off-by: Emanuele Aina's avatarEmanuele Aina <emanuele.aina@collabora.com>
  25. 06 May, 2021 1 commit
  26. 28 Apr, 2021 5 commits