1. 17 Feb, 2021 1 commit
  2. 15 Feb, 2021 1 commit
  3. 07 Jan, 2021 1 commit
  4. 18 Dec, 2020 2 commits
  5. 17 Dec, 2020 2 commits
  6. 16 Dec, 2020 1 commit
  7. 15 Dec, 2020 1 commit
  8. 24 Nov, 2020 1 commit
    • Benjamin Tissoires's avatar
      CI: add a job to allow to continue the pipeline · f69e79f4
      Benjamin Tissoires authored
      
      
      If a distribution pipeline fails, the parent trigger job will be updated,
      but the pipeline will not continue. It's a gitlab upstream issue, but
      until it is fixed, add a workaround for it:
      - we add a new stage right after the children pipelines which will be
        always run
      - the jobs reflects the status of the total children pipelines
      - when the downstream piplines are fixed, we can manually retrigger this
        job, and continue the pipeline
      Signed-off-by: Benjamin Tissoires's avatarBenjamin Tissoires <benjamin.tissoires@gmail.com>
      f69e79f4
  9. 23 Nov, 2020 2 commits
    • Peter Hutterer's avatar
      ci-fairy: fix generate-template --verify · 16f790f9
      Peter Hutterer authored
      
      
      The previous version struggled with trailing linebreaks. Fix that by making
      sure we ignore any changes on the final newline (Jinja2 doesn't write those
      out anyway).
      
      Let's make sure we read, split and rejoin old and new data in exactly the same
      way so we don't have to deal with stray line endings.
      
      And the generator returned by difflib is always True. Unclear why this worked
      in my local tests when I wrote the original support...
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      16f790f9
    • Andres Gomez's avatar
      ci-fairy: do not import git from the top · 8445ff7a
      Andres Gomez authored
      
      
      The GitPython module depends in the git command.
      
      Installing git pulls quite some dependencies: eg. in a Debian Buster
      system it increases the used space in ~100MB.
      
      We may want to use some of the ci-fairy commands in systems with
      constrained space. Since git is used only in some of the commands,
      let's import only when it's really needed.
      
      v2:
        - Remove the get_git() helper and patch the git module at
          sys.modules in the tests (Peter).
      Signed-off-by: Andres Gomez's avatarAndres Gomez <agomez@igalia.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      8445ff7a
  10. 22 Nov, 2020 2 commits
  11. 20 Nov, 2020 2 commits
  12. 19 Nov, 2020 5 commits
  13. 18 Nov, 2020 4 commits
    • Peter Hutterer's avatar
      ci-fairy: add a --verify command to generate-template · 43ac932d
      Peter Hutterer authored
      
      
      A number of projects have a job that runs generate-template followed by a diff
      to make sure the generated file is the one checked in. Let's remove the manual
      diff step from that and provide it as built-in functionality from ci-fairy.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      [re-run generate_templates.py after rebase]
      Signed-off-by: Benjamin Tissoires's avatarBenjamin Tissoires <benjamin.tissoires@gmail.com>
      43ac932d
    • Peter Hutterer's avatar
      Publish the ci-fairy image on quay.io · b824e03b
      Peter Hutterer authored
      
      
      Same motivation as the buildah images - it allows others to use the image
      without having to pull it from our gitlab registry.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      b824e03b
    • Peter Hutterer's avatar
      Move the ci-fairy template to a separate file · 6789d7d6
      Peter Hutterer authored
      
      
      Having a separate file gives us slightly more flexibility what we can
      provide in terms of templates from ci-fairy. It also provides the option of
      updating ci-fairy independently from the base templates in case we don't
      want to rebuild a project's containers but want to make use of some new
      ci-fairy feature.
      
      We re-use the existing infrastructure for the template generation by calling
      the ci-fairy template a distribution because there's about 70% overlap
      anyway. Unfortunately, because there is only 70% the other 30% need to be
      special-cased now. So we add a few checks for a 'distribution' to provide
      custom templates and stages.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      6789d7d6
    • Peter Hutterer's avatar
      Build a custom ci-fairy capable image · d69e2849
      Peter Hutterer authored
      
      
      It's easy enough to install ci-fairy via pip from git, but doing so requires
      an image that's capable of pip. This again means either alpine from
      docker (it's small but we'll be ratelimited very soon), or some other image
      that each project generates on its own.
      
      Let's assume that several projects have common requirements for a small
      reusable image: either basic git checks, python+pip (e.g. flake8 checks) or
      ci-fairy. And that we don't want to run afoul docker hub's pull limits, so
      we have a need to host this image locally.
      
      This patch adds it as the .fdo.ci-fairy template to every
      distribution-specific template. This is just for convenience, the image
      itself is always the same and not based on that distribution. So where any
      template is included, ci-fairy can be used like this:
      
         check-mr:
           extends:
             - .fdo.ci-fairy
           script:
            - ci-fairy check-merge-request --require-allow-collaboration
      
      The image itself is built in two stages:
      - a private base image with the required packages installed
      - the actual public image with ci-fairy pip-installed
      
      The tag for the public image is the sha256sum of the ci_fairy.py file. This
      way we only rebuild the image when the source itself changes and new images
      are tiny as the base layer is deduplicated across images.
      
      The .fdo.ci-fairy template hardcodes that sha, so projects will keep
      pulling the same image until they bump the ci-templates ref.
      
      And now that we're shipping an image, let's set FDO_UPSTREAM_REPO.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      d69e2849
  14. 10 Nov, 2020 2 commits
    • Peter Hutterer's avatar
      Use the python:alpine image for the pip jobs · 9df1fca3
      Peter Hutterer authored
      
      
      This image is a mere 12MB to pull and it comes with pip, so let's use that
      instead of the large Fedora image for jobs where we just run a single script
      early in the CI.
      
      The first test pipelines show that the check-commit job finishes in under
      30s now (over a minute before). And dnf synching is already 100M to download
      + time, we're a lot faster with this image.
      
      We only have /bin/sh on this image but the only bash job we were running was
      the doc build - and that can easily be debashified.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      9df1fca3
    • Peter Hutterer's avatar
      gitlab CI: add a test stage for images published to quay.io · 52853aa6
      Peter Hutterer authored
      
      
      Scour the templates for any `image: quay.io/....` key and collect those. Check
      that those images exist with a simple skopeo inspect job at the end of the
      pipeline.
      
      This works because our images are fully hardcoded, there are no variables
      within the image specifier. If that ever changes, this part needs to be
      adjusted.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      52853aa6
  15. 05 Nov, 2020 3 commits
    • Jonas Ådahl's avatar
      Sprinkle architecture awareness · 9673e0a1
      Jonas Ådahl authored
      
      
      This means jobs or abstract jobs that are specific to a single
      archtecture now all are postfixed with that architecture. That means
      e.g. .bootstrap became .bootstrap@x86_64, while .bootstrap@aarch64
      remained the same.
      
      For the jobs it the CI pipeline, fedora:ci@container-build became
      fedora:ci@container-build@x86_64, alpine:latest@container-build became
      alpine:latest@container-build@x86_64, debian@cache-container-build
      became debian@cache-container-build@x86_64, and so on.
      
      The distribution images does not have the archtecture in the name due to
      a limitation in the number of subdirectories allowed in the gitlab
      registry. Instead the achitecture is added to the relevant tag. That
      means that fdo-ci-221155 became fdo-ci-x86_64-221155, while the image
      remained at e.g ../ci-templates/alpine/latest.
      
      This confusingly means that aarch64 builds, previously seemingly
      extending "generic" abstract jobs, now extend x86_64 ones, and while
      this looks confusing is how it worked in practice already.
      Signed-off-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      9673e0a1
    • Jonas Ådahl's avatar
      Add publish stage pushing images to quay.io · 597b24f4
      Jonas Ådahl authored
      
      
      This splits up the template variable into registry domain and path, so
      that one can 'podman login domain'.
      Signed-off-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      597b24f4
    • Jonas Ådahl's avatar
      Rename arm64v8 to aarch64 · 69c91925
      Jonas Ådahl authored
      
      
      We'll later be more explicit about architectures, so to make their
      difference clear, avoid 'amd64' and 'arm64' and refer to the
      architectures as 'x86_64' and 'aarch64'.
      Signed-off-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      69c91925
  16. 31 Aug, 2020 1 commit
  17. 06 Jul, 2020 1 commit
  18. 20 Jun, 2020 1 commit
  19. 15 Jun, 2020 1 commit
  20. 11 Jun, 2020 1 commit
    • Peter Hutterer's avatar
      tools: add commit message checks to ci-fairy · 639808ac
      Peter Hutterer authored
      
      
      Useful for checking things like signed-off-by and some more cosmetic things
      that we expect in general from the commit message.
      
      Current checks:
      - s-o-b present or not (depending on commandline toggle)
      - textwidth < 80 chars
      - second line of commit message is an empty line
      - no 'fixup!' or 'squash!' messages in the history
      - git author information is set
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      639808ac
  21. 04 Jun, 2020 1 commit
  22. 02 Jun, 2020 1 commit
  23. 25 Apr, 2020 1 commit
  24. 24 Apr, 2020 1 commit
  25. 23 Mar, 2020 1 commit
    • Peter Hutterer's avatar
      Provide a vmctl start|start-kernel|stop|exec command · acda94e1
      Peter Hutterer authored
      
      
      This wraps the common things we need to do - start the vm, stop it later and
      in between exec a few commands on the VM itself.
      
      exec is just a wrapper around ssh and vmctl start installs a ssh_config.d
      entry so we can acces the vm as host "vm". This simplifies our scp calls a lot
      too since we don't need to know about the port anymore and calling it "vm" is
      less confusing than "localhost".
      
      FTR, I did have a vmctl copy command in the test branch but it ended up being
      worse than just calling scp - the argument for exec is weak enough as it is.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      acda94e1