1. 17 May, 2022 1 commit
  2. 09 May, 2022 1 commit
    • Emanuele Aina's avatar
      Always reset the git repostiory after adding gitattributes · eb79b4f9
      Emanuele Aina authored
      Commit 477e59b5
      
       "Reset the git repostiory after adding gitattributes"
      ensured on the `pull-mirror` job that the checked out contents match
      the current gitattributes configuration.
      
      This extends such guarantee to all jobs, avoiding situations like:
      
      1. the upstream `.gitattributes` enables the `ident` filter on a file
      2. on checkout by the CI, `$Id$` placeholders are replaced
      3. we defuse the `.gitattributes`, but it is too late since the working
         copy is already dirty
      4. jobs like `pull-updates` fail due to the unexpected changes
      Signed-off-by: Emanuele Aina's avatarEmanuele Aina <emanuele.aina@collabora.com>
      eb79b4f9
  3. 01 May, 2022 3 commits
  4. 30 Apr, 2022 3 commits
  5. 25 Apr, 2022 1 commit
  6. 29 Mar, 2022 3 commits
  7. 10 Mar, 2022 1 commit
  8. 09 Mar, 2022 1 commit
  9. 16 Feb, 2022 1 commit
  10. 09 Feb, 2022 2 commits
  11. 08 Feb, 2022 2 commits
    • Ritesh Raj Sarraf's avatar
      Document the extra apt repository feature · b12566c8
      Ritesh Raj Sarraf authored
      
      
      This MR documents the Extra APT Repository feature with some example
      screenshots.
      Signed-off-by: Ritesh Raj Sarraf's avatarRitesh Raj Sarraf <ritesh.sarraf@collabora.com>
      b12566c8
    • Ritesh Raj Sarraf's avatar
      add extra apt repository · e143de11
      Ritesh Raj Sarraf authored
      It is desirable to inject extra apt repository to pull in packages from.
      This is useful in scenarios where packages from one repository could
      have (build) dependencies from other repositories.
      
      This feature expects 3 environment variables, from which it constructs
      the extra apt repository information
      
      * EXTRA_REPO_BASE_URL: https://repositories-apertispro.boschdevcloud.com
      * EXTRA_REPO_VERSION: unset (we want to derive from branch name here)
      * EXTRA_REPO_COMPONENTS: "hmi target development sdk"
      
      The base url also supports password protected repositories, in the form
      of: https://username:password@hostname/
      
      
      
      The repository version may be specified from the environment variable.
      In the absence of the value, it is determined from the current branch
      name, like: `apertis/v2022`, which will result in the release name as:
      `v2022`
      
      Multiple components can be specified, separated by space.
      
      These environment variables can be fed to the CI build environment
      throuh the CI variable settings, on a per repository basis, or for
      entire repository groups
      Signed-off-by: Ritesh Raj Sarraf's avatarRitesh Raj Sarraf <ritesh.sarraf@collabora.com>
      e143de11
  12. 07 Feb, 2022 3 commits
    • Ryan Gonzalez's avatar
    • Ryan Gonzalez's avatar
      Use GitLab environments to clean up branched OBS projects · a93c70d4
      Ryan Gonzalez authored
      
      
      This will preserve the project until the corresponding branches are
      deleted or the MR is merged, as well as being more reliable in
      performing the cleanup tasks.
      Signed-off-by: Ryan Gonzalez's avatarRyan Gonzalez <ryan.gonzalez@collabora.com>
      a93c70d4
    • Ryan Gonzalez's avatar
      Properly fix backport MRs breaking release pipelines · 500eebbe
      Ryan Gonzalez authored and Emanuele Aina's avatar Emanuele Aina committed
      ci-package-builder's extensive use of `rules:` means that every push to
      an MR branch results in *two* pipelines: one outside the MR context
      (i.e. for the branch itself) and one in the MR's context:
      
      https://docs.gitlab.com/ee/ci/jobs/job_control.html#avoid-duplicate-pipelines
      
      In order to work around this, `run_on_mr_xor_branch_rule` is used, which
      will only run a pipeline iff either a) there is no MR, or b) it is
      running inside the MR context. That way, pipelines will run against
      plain branches normally, but once an MR is opened, only the MR pipelines
      will be run. (Running them in MR context is preferred because then we
      can use the target branch name to figure out what release is being
      targeted by the MR.)
      
      However, if:
      
      - An MR is merged against a release branch, e.g. `apertis/v2023dev1`
      - The release pipeline encounters an error, or it cannot be run yet due
        to CI load.
      - A new MR is opened to backport the changes, e.g. `apertis/v2023dev1`
        -> `apertis/v2022`.
      - The original release pipeline for `apertis/v2023dev1` is now run or
        re-run.
      
      Because an MR is open with `apertis/v2023dev1`,
      `run_on_mr_xor_branch_rule` will now prevent the release pipeline from
      running at all.
      
      !228 was intended to fix this, but instead it resulted in backport MRs
      uploading their CI results to the release repos (!231
      
      ). Instead, we can
      just change `run_on_mr_xor_branch_rule` to exclude blocking release
      branches, so their pipelines can run normally.
      Signed-off-by: Ryan Gonzalez's avatarRyan Gonzalez <ryan.gonzalez@collabora.com>
      500eebbe
  13. 05 Feb, 2022 1 commit
    • Emanuele Aina's avatar
      Avoid mistakenly uploading to target projects from open MRs · 950071ff
      Emanuele Aina authored
      
      
      The current code falls back to `$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME`
      when figuring out if a branched OBS project should be the target of
      the upload:
      
          if [[ ${CI_COMMIT_BRANCH:-$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME} != $OSNAME/* ]];
          then
            # upload to branched OBS project
          fi
      
      The big bug is that a MR for a backport going straight from
      `apertis/v2023dev1` to `apertis/v2022` will skip the body of that `if`
      and will actually upload to the production `apertis:v2022:*` OBS
      project as soon the MR is **created** rather than when it is merged.
      
      On a MR we should always upload to a branched project: to do that, we
      can rely on the fact that `$CI_COMMIT_BRANCH` is not set in merge
      request context and simply drop the fallback.
      Signed-off-by: Emanuele Aina's avatarEmanuele Aina <emanuele.aina@collabora.com>
      950071ff
  14. 04 Feb, 2022 1 commit
  15. 03 Feb, 2022 1 commit
  16. 02 Feb, 2022 1 commit
    • Emanuele Aina's avatar
      Fix MRs for backports that fail to upload · f13b2a49
      Emanuele Aina authored
      
      
      When creating a backport MR, for instance from `apertis/v2023dev1` to
      `apertis/v2022`, the HEAD will have a release tag created when it landed
      on the apertis/v2023dev1` branch.
      
      The presence of the tag causes the `build-source` job to exit early, but
      that meant that no `_build` artifacts directory is populated.
      
      The `upload` job will not have anything to upload to OBS and will fail.
      
      Extract the tagged source from the `pristine-lfs-source` branch in the
      `build-source` job as well to have it ready for `upload`.
      Signed-off-by: Emanuele Aina's avatarEmanuele Aina <emanuele.aina@collabora.com>
      f13b2a49
  17. 01 Feb, 2022 1 commit
  18. 19 Jan, 2022 1 commit
  19. 14 Jan, 2022 1 commit
  20. 31 Dec, 2021 1 commit
  21. 28 Dec, 2021 2 commits
  22. 23 Dec, 2021 1 commit
  23. 22 Dec, 2021 1 commit
  24. 20 Dec, 2021 2 commits
    • Emanuele Aina's avatar
      pull-updates: Land Bullseye updates to the default branch · a31cdaf2
      Emanuele Aina authored
      
      
      No need to tweak the destination branch every time we branch a new
      release, just target the default branch.
      
      This is not 100% the same thing: packages that got dropped at some point
      will have the default branch set to a different release (for instance,
      `apertis/v2021`).
      
      In those cases, either:
      1. no `debian/bullseye` branch exist, so this is not an issue
      2. if we want to land the `debian/bullseye` updates somewhere, trying
         with a non-existent branch name is not very useful anyway
      Signed-off-by: Emanuele Aina's avatarEmanuele Aina <emanuele.aina@collabora.com>
      a31cdaf2
    • Emanuele Aina's avatar
      pull-updates: Fix upstream updates from -security branches · 72e0659d
      Emanuele Aina authored and Vignesh Raman's avatar Vignesh Raman committed
      
      
      Always normalize the upstream release information. This means that when
      triggering the pull from the `debian/buster-security` branch we behave
      exactly like when triggering from `debian/buster`.
      
      This fixes pipeline failures where we tried to push
      `upstream/buster-security` instead of `upstream/buster`.
      Signed-off-by: Emanuele Aina's avatarEmanuele Aina <emanuele.aina@collabora.com>
      72e0659d
  25. 19 Dec, 2021 1 commit
  26. 18 Dec, 2021 1 commit
    • Emanuele Aina's avatar
      tests: Be more patient when waiting for GitLab · 92f2eca5
      Emanuele Aina authored
      
      
      It seems that the pipeline is getting increasingly flaky due to GitLab
      needing more time to react to our actions (due to load, increased
      asynchronousness, or whatever).
      
      Given our test job takes more than 30 minutes to complete, restarting
      it is quite costly and we can instead easily afford to increase the wait
      time when retrying actions on GitLab.
      Signed-off-by: Emanuele Aina's avatarEmanuele Aina <emanuele.aina@collabora.com>
      92f2eca5
  27. 17 Dec, 2021 1 commit
  28. 15 Dec, 2021 1 commit