1. 17 Feb, 2021 3 commits
  2. 20 Nov, 2020 9 commits
  3. 19 Nov, 2020 4 commits
  4. 18 Nov, 2020 5 commits
    • Peter Hutterer's avatar
      Use a sha256sum instead of a hacky sha addition to the dictionary · e3d23bc9
      Peter Hutterer authored
      Similar to 766e3d77
      , add the sha256sum to
      Jinja's global namespace and then generate them in the templates.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
    • 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>
    • 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:
             - .fdo.ci-fairy
            - 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>
    • Peter Hutterer's avatar
      Move the templates lookup into the loop · b52a7c33
      Peter Hutterer authored
      No functional change, this is prep work for an upcoming patch.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
    • Peter Hutterer's avatar
      Fix the check for defaults.yml · 635b4f32
      Peter Hutterer authored
      Technically, the string 'defaults.yml' is in 'defaults.yml' but this is a
      rather odd way to check.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
  5. 10 Nov, 2020 1 commit
  6. 20 Jun, 2020 1 commit
  7. 25 Apr, 2020 1 commit
  8. 24 Apr, 2020 1 commit
  9. 16 Mar, 2020 1 commit
  10. 05 Dec, 2019 1 commit
  11. 29 Nov, 2019 4 commits