Skip to content
Snippets Groups Projects
  1. Apr 29, 2020
  2. Apr 06, 2020
  3. Mar 27, 2020
  4. Mar 26, 2020
  5. Mar 25, 2020
  6. Mar 23, 2020
  7. Mar 18, 2020
  8. Mar 12, 2020
  9. Feb 28, 2020
    • Ritesh Raj Sarraf's avatar
      Push packages to release repositories without an SR · 37326244
      Ritesh Raj Sarraf authored
      With our workflow, where the CI has 2 steps:
      1. deploy-snapshot
      2. deploy-release
      
      It becomes cumbersome and unnecessary to create SRs on OBS for each
      package. During deploy-snapshot, we already test the fact if our package
      has built successfully. So, during deploy-release, we want to upload the
      package to the release repository.
      
      We don't do cleanups of the package in the :snapshot repository, because
      they get autocleaned there anyways.
      
      Check for the $RELEASE variable to ascertain if it is a release build or
      otherwise
      
      Also, print the repository to which the package is uploaded to.
      
      APERTIS: https://phabricator.apertis.org/T6658
      
      
      
      Signed-off-by: default avatarRitesh Raj Sarraf <ritesh.sarraf@collabora.com>
      
      Apply comments from Emanuele
      37326244
  10. Feb 21, 2020
  11. Feb 19, 2020
  12. Feb 18, 2020
  13. Feb 11, 2020
  14. Feb 10, 2020
  15. Feb 06, 2020
  16. Jan 30, 2020
  17. Jan 28, 2020
  18. Jan 24, 2020
    • Emanuele Aina's avatar
      apertis-pkg-merge-updates: Do not abort failed merges · 426bd702
      Emanuele Aina authored
      
      When a merge fails, it's nice to let developers use the same tools as used by
      the CI to reproduce and fix the issue.
      
      Unfortunately, `apertis-pkg-merge-updates` cleans up after itself a bit too
      much, aborting the merge and thus preventing developer from fixing it.
      Stop doing that so that developers can handle the conflicts, GitLab CI will
      clean up after itself in any case.
      
      Signed-off-by: Emanuele Aina's avatarEmanuele Aina <emanuele.aina@collabora.com>
      426bd702
  19. Jan 17, 2020
    • Andrej Shadura's avatar
      scripts: Disable http pipelining similarly to what 7456f3f7 did · 85165fd2
      Andrej Shadura authored
      
      It seems http pipeline sometimes causes broken downloads; while this really
      needs fixing in apt, work it around for now so CI doesn’t hit it.
      
      Signed-off-by: default avatarAndrej Shadura <andrew.shadura@collabora.co.uk>
    • Andrej Shadura's avatar
      Move Docker image building from Jenkins to GitLab CI · 2900db0f
      Andrej Shadura authored
      
      Instead of building all images individually, try and build Apertis-based
      ones from the same common ground. First create a fairly basic Apertis
      ospack with a few development tools in, then create a Docker image out of
      it and layer things on top of it.
      
      This unifies the previously separate overlays for the package builder and
      the package source builder, only keeping the real differences in their
      respective overlays.
      
      We opt to not use Docker proper since it requires non-trivial
      Docker-in-Docker setup. Makisu, which could be used as an alternative,
      unfortunately, has buggy implementation of the ADD command, leaving us
      the only option to use Kaniko.
      
      The docker building step is templated in .gitlab-ci.yml to avoid
      repetition. The Debian-based images don’t normally have to depend on the
      rootfs building step, but to be able to run them asynchronously in the
      same pipeline stage we need to declare the dependency anyway, as GitLab CI
      does not currently support empty "needs" lists.
      
      The branches named apertis/* build their respective Apertis releases,
      everything else builds the default defined in the CI YAML file.
      
      The jobs for apertis/* branches tag their build images as "latest", every
      other job uses the branch name.
      
      For robustness, the debos rootfs step uses a stable v2020 image builder
      step instead of the currently built one.
      
      Signed-off-by: default avatarAndrej Shadura <andrew.shadura@collabora.co.uk>
  20. Jan 13, 2020
    • Emanuele Aina's avatar
      package-source-builder: Fix tally-revision on new repositories · 16447abb
      Emanuele Aina authored
      
      The `tally-revision` script used to skip revision for which a package has
      been built already does not really work on new repositories that do not
      contain any tag.
      
      In that scenario it fails like this:
      
        $ tally-revision
        + git rev-parse -q --verify HEAD
        + HEAD=2a2235e0f7182fcc619e755eb14de0983753c6cf
        + git describe --tags --match apertis/* --abbrev=0
        fatal: No names found, cannot describe anything.
        +TAGS=
      
      That's because `set -e` causes the failing `git describe` invocation to exit
      the script with an error, which is then interpreted as "skip this revision",
      preventing the pipeline from running on new repositories with no tags.
      
      Signed-off-by: Emanuele Aina's avatarEmanuele Aina <emanuele.aina@collabora.com>
      16447abb
  21. Jan 08, 2020
  22. Jan 06, 2020
  23. Jan 03, 2020
Loading