1. 26 Feb, 2021 1 commit
  2. 07 Jan, 2021 1 commit
  3. 18 Dec, 2020 1 commit
  4. 15 Dec, 2020 1 commit
  5. 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>
    • 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.
        - 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>
  6. 22 Nov, 2020 2 commits
  7. 20 Nov, 2020 2 commits
  8. 19 Nov, 2020 5 commits
  9. 18 Nov, 2020 1 commit
  10. 17 Nov, 2020 1 commit
  11. 16 Nov, 2020 1 commit
    • 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}}-{{
                                 '.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>
  12. 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>
  13. 12 Nov, 2020 1 commit
  14. 25 Oct, 2020 1 commit
  15. 31 Aug, 2020 1 commit
  16. 06 Jul, 2020 1 commit
  17. 30 Jun, 2020 3 commits
  18. 18 Jun, 2020 1 commit
  19. 15 Jun, 2020 1 commit
  20. 14 Jun, 2020 3 commits
  21. 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>
  22. 10 Apr, 2020 1 commit
  23. 17 Mar, 2020 7 commits