1. 17 Feb, 2021 1 commit
  2. 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
  3. 20 Nov, 2020 2 commits
  4. 19 Nov, 2020 4 commits
  5. 18 Nov, 2020 2 commits
    • 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
  6. 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
  7. 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
  8. 31 Aug, 2020 1 commit
  9. 06 Jul, 2020 1 commit
  10. 20 Jun, 2020 1 commit
  11. 15 Jun, 2020 1 commit
  12. 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
  13. 04 Jun, 2020 1 commit
  14. 02 Jun, 2020 1 commit
  15. 25 Apr, 2020 1 commit
  16. 24 Apr, 2020 2 commits
  17. 17 Mar, 2020 1 commit
  18. 16 Mar, 2020 1 commit
  19. 10 Mar, 2020 4 commits
  20. 04 Mar, 2020 1 commit
    • Peter Hutterer's avatar
      doc: add sphinx docs · 97e5b293
      Peter Hutterer authored
      
      
      This just the most basic scaffolding and build script to hook up to gitlab
      pages. Actual docs need to be added.
      
      The build script is a minimal wrapper around the sphinx-build command but this
      way we can easily ensure that local rebuilding of the docs produces the same
      output that gitlab pages will display.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      97e5b293
  21. 19 Feb, 2020 1 commit
  22. 11 Dec, 2019 3 commits
  23. 05 Dec, 2019 3 commits
  24. 02 Dec, 2019 1 commit