1. 21 Sep, 2020 2 commits
  2. 01 Sep, 2020 1 commit
  3. 04 Aug, 2020 2 commits
  4. 03 Jun, 2020 1 commit
  5. 07 May, 2020 3 commits
    • Daniel Berrange's avatar
      gitlab: add CONTRIBUTING.rst file to indicate use of merge requests · e48fa355
      Daniel Berrange authored
      With the introduction of automated CI pipelines, we are now ready to switch
      to using merge requests for the project. With this switch we longer wish
      to have patches sent to the mailing list, and thus the git-publish
      config is removed.
      Signed-off-by: Daniel Berrange's avatarDaniel P. Berrangé <[email protected]>
    • Daniel Berrange's avatar
      gitlab: add a simple job that publishes the API docs as HTML · 7ed71e26
      Daniel Berrange authored
      The Perl modules have inline POD docs. This can be converted to HTML and
      published as a GitLab artifact. The rendered HTML is kind of ugly but
      improving this is left as an exercise for the future.
      Signed-off-by: Daniel Berrange's avatarDaniel P. Berrangé <[email protected]>
    • Daniel Berrange's avatar
      gitlab: add CI jobs for validating build across platforms · 656e7ddc
      Daniel Berrange authored
      This introduces CI jobs that replace the current jobs used on Jenkins
      for every platform except FreeBSD.
      A merge request workflow requires the user to fork the primary git
      repo into their personal namespace. In general the changes need to
      be tested against the current libvirt git master. If the user has a
      fork of the main libvirt repo, we don't want to use that by default
      as it may be out of date.
      The general goal is that the CI jobs are self-contained and don't
      depend on the build artifacts from the libvirt repo. We also want
      to avoid having an explicit dependency on the libvirt-ci repo, or
      on the Quay.io service. Contributors to the Perl module need to be
      able to make code changes which imply CI environment changes and
      be able to test them in isolation.
      Thus, the dockerfile recipes for each distro are added in the ci/
      sub-directory. The first stage of the CI jobs is to use these
      recipes to build and publish a container image. These images are
      then used in the second stage to perform the actual build.
      The container image build is cached, inheriting from both the
      primary libvirt project namespace, and the user's private project
      namespace. Thus the performance hit of building container images
      will only be felt the first time the project is forked, or when
      the parent Docker images are rebuilt.
      The dockerfiles were originally generated using lcitool, but if
      the user makes a change that introduces new build dependencies,
      the corresponding packages can be added to the dockerfile recipes
      directly in the same commit. The change can be propagated back
      into the libvirt-ci.git repo asynchronously.
      The build job will do a minimal(-ish) build of libvirt git master
      and then build the rest of the code against that. Ideally the main
      libvirt configure script would have a way to request a minimal
      build of just the API and test driver, but for now we settle for
      just --without-libvirt which culls a large number of the drivers
      fairly easily.
      Signed-off-by: Daniel Berrange's avatarDaniel P. Berrangé <[email protected]>
  6. 05 May, 2020 2 commits
  7. 01 May, 2020 1 commit
  8. 28 Apr, 2020 1 commit
  9. 23 Apr, 2020 1 commit
  10. 07 Apr, 2020 2 commits
    • Daniel Berrange's avatar
      github: enable lockdown of issues and merge requests · 9a8dc8e5
      Daniel Berrange authored
      Libvirt uses GitHub as an automated read-only mirror. The goals were to
      have a disaster recovery backup for libvirt.org, a way to make it easy
      for people to clone their own private copy of libvirt Git, and finally
      as a way to interact with apps like Travis.
      The project description was set to a message telling people that we
      don't respond to pull requests. This was quite a negative message to
      potential contributors, and also did not give them any guidance about
      the right way to submit to libvirt. Many also missed the description and
      submitted issues or pull requests regardless.
      It is possible to disable the issue tracker in GitHub, but there is no
      way to disable merge requests. Disabling the issue tracker would also
      leave the problem of users not being given any positive information
      about where they should be reporting instead.
      There is a fairly new 3rd party application built for GitHub that
      provides a bot which auto-responds to both issues and merge requests,
      closing and locking them, with a arbitrary comment:
      This commit adds a suitable configuration file for libvirt, which
      tries to give a positive response to user's issue/pullreq and guide
      them to the desired contribution path on GitLab.
      Reviewed-by: Andrea Bolognani's avatarAndrea Bolognani <[email protected]>
      Reviewed-by: Pavel Hrdina's avatarPavel Hrdina <[email protected]>
      Reviewed-by: Eric Blake's avatarEric Blake <[email protected]>
      Signed-off-by: Daniel Berrange's avatarDaniel P. Berrangé <[email protected]>
    • Daniel Berrange's avatar
  11. 03 Apr, 2020 1 commit
  12. 10 Mar, 2020 1 commit
  13. 09 Mar, 2020 1 commit
  14. 10 Feb, 2020 1 commit
  15. 16 Jan, 2020 5 commits
  16. 10 Jan, 2020 1 commit
  17. 11 Dec, 2019 2 commits
  18. 10 Dec, 2019 6 commits
  19. 06 Dec, 2019 1 commit
  20. 04 Dec, 2019 1 commit
  21. 03 Dec, 2019 2 commits
  22. 02 Dec, 2019 2 commits