1. 19 Mar, 2021 1 commit
  2. 07 Jan, 2021 1 commit
  3. 18 Dec, 2020 1 commit
  4. 20 Nov, 2020 2 commits
  5. 19 Nov, 2020 2 commits
  6. 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
  7. 16 Nov, 2020 3 commits
    • Thomas Haller's avatar
      ci-fairy: add "ci_fairy.hashfiles()" function to global Jinja2 environment · 766e3d77
      Thomas Haller authored
      
      
      We build the containers by running an install script. When the
      script changes, we usually want to re-generate the containers.
      
      That is easy to miss. We could improve that by embedding a checksum
      of the file as a comment in ".gitlab-ci.yml"
      
         {% for distro in distributions %}
           {{"%-13s"| format(distro.name.upper() + '_EXEC:')}}'bash .gitlab-ci/{{distro.name}}-install.sh' # {{ ci_fairy.hashfiles('.gitlab-ci/' + distro.name + '-install.sh') }}
         {% endfor %}
      
      which results in
      
         FEDORA_EXEC: 'bash .gitlab-ci/fedora-install.sh' # db512ed0d3f6880a01ab29cba42abc233f56a7eab1f8ee9a83031f9244b84288
         UBUNTU_EXEC: 'bash .gitlab-ci/ubuntu-install.sh' # 6e35a936aba079f4d91eece147f77d3f65cdc562308a680018a2035a6efdbf2e
      
      As we have a test that compares ".gitlab-ci.yml" to the output of
      `ci-fairy generate-template`, the comment would be a reminder that
      we should bump the tag and re-generate ".gitlab-ci.yml".
      
      Alternatively, we could make the hash part of the distro-tag
      
         {% for distro in distributions %}
           {{"%-13s"| format(distro.name.upper() + '_TAG:')}}'{{distro.tag}}-{{
             (ci_fairy.hashfiles('.gitlab-ci/config.yml',
                                 '.gitlab-ci/ci.template',
                                 '.gitlab-ci/' + distro.name + '-install.sh'))[0:12]
           }}'
         {% endfor %}
      
      which results in
      
         FEDORA_TAG:  '2020-11-10.0-b137473ad957'
         UBUNTU_TAG:  '2020-11-10.0-542ace328cfb'
      Signed-off-by: Thomas Haller's avatarThomas Haller <thaller@redhat.com>
      766e3d77
    • Peter Hutterer's avatar
    • Peter Hutterer's avatar
      4225a9b4
  8. 13 Nov, 2020 1 commit
    • Peter Hutterer's avatar
      ci-fairy: add a wait-for-pipeline command · 08d0abcd
      Peter Hutterer authored
      
      
      Sometimes, running a CI pipeline is a game of whack-a-mole with the various
      configurations and different build targets. Let's add a ci-fairy command that
      can be run after pushing to wait for the current pipeline(s) to finish.
      
      Usage: ci-fairy wait-for-pipeline
      
      There are a few optional arguments, but most of the time it should find the
      information itself. It picks HEAD from cwd by default, figures out the repo
      etc. and then monitors the running pipeline.
      
      Note that the repo lookup is *not* using the git config because we cannot know
      which repository is the intended one. We cannot use the current branch's
      upstream either because there's a reasonable chance it's origin/master.
      
      So we just assume that the pipeline after pushing runs in the user fork,
      defined by $GITLAB_USER_ID (or as fallback $USER). Where this isn't
      sufficient, specify --project.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      08d0abcd
  9. 15 Jun, 2020 1 commit
  10. 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
  11. 04 Jun, 2020 1 commit
  12. 20 Mar, 2020 1 commit
  13. 17 Mar, 2020 4 commits