.gitignore | 1 + .gitlab-ci.yml | 74 +++++++++++++++++ .travis.yml | 78 +++++------------ Makefile.am | 2 + Makefile.ci | 222 +++++++++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 321 insertions(+), 56 deletions(-) create mode 100644 .gitlab-ci.yml create mode 100644 Makefile.ci
For a while QEMU has provided simple make rules for building QEMU inside standard docker container environments. This provides an equivalent mechanism for libvirt inspired by QEMU's. QEMU actually builds the container images on developer's machines locally. Libvirt already hosts pre-built images on quay.io, so that is used directly as it is quicker to download them than to build them locally. This also ensures the container contents match what the live CI system is using, as opposed to building an image with newer packages. Changed in v4: - Re-add cross-compilation patches now that containers exist - Add CI_ prefix on all variables to avoid clashing with automake defined variables - Fix path given to -f arg for ci-check target - Remove dead code - Fix check for submodule checkout existing - Ensure macOS Homebrew is updated Changed in v3: - Lots of new variables & variable renames - Rename to top level Makefile.ci - Rename make targets to have @ separator for the image - Refactor macOS travis config Changed in v2: - Drop cross-compilation patches temporarily. The cross-compiler images are not yet built on quay.io and rather than creating and bulding many more images manually, I'm working on script to automate setup of quay.io images - Many changes to the make rules to make it possible to use them from Travis CI to match its currently testing setup - Modify Travis CI config to use the new make rules for consistency Daniel P. Berrangé (7): tests: add targets for building libvirt inside Docker containers travis: convert Ubuntu, CentOS & MinGW builds to use new make rules travis: use declarative syntax for Homebrew packages travis: remove display of test-suite.log from macOS travis: put macOS script inline in the macOS matrix entry tests: add cross compiler images to CI test help output tests: perform cross compiler builds on GitLab CI .gitignore | 1 + .gitlab-ci.yml | 74 +++++++++++++++++ .travis.yml | 78 +++++------------ Makefile.am | 2 + Makefile.ci | 222 +++++++++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 321 insertions(+), 56 deletions(-) create mode 100644 .gitlab-ci.yml create mode 100644 Makefile.ci -- 2.20.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Apr 03, 2019 at 11:41:41AM +0100, Daniel P. Berrangé wrote: >For a while QEMU has provided simple make rules for building QEMU inside >standard docker container environments. This provides an equivalent >mechanism for libvirt inspired by QEMU's. > Can we change this so that we don't mention docker everywhere? These are just containers and you can run them using other tools with no docker dependency. I know I can set an alias docker=podman and it will just work, but now that podman, buildah, skopeo and others work on my machine (even non-systemd one) I think it would be nice stop requiring "docker" if it is not needed. And to make Dan Walsh not cringe that much. Nice patch series, I hope I'll get to testing it sooner rather than later. Have a nice day Martin -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Apr 03, 2019 at 02:29:55PM +0200, Martin Kletzander wrote: > On Wed, Apr 03, 2019 at 11:41:41AM +0100, Daniel P. Berrangé wrote: > > For a while QEMU has provided simple make rules for building QEMU inside > > standard docker container environments. This provides an equivalent > > mechanism for libvirt inspired by QEMU's. > > > > Can we change this so that we don't mention docker everywhere? These are just > containers and you can run them using other tools with no docker dependency. I > know I can set an alias docker=podman and it will just work, but now that > podman, buildah, skopeo and others work on my machine (even non-systemd one) I > think it would be nice stop requiring "docker" if it is not needed. And to make > Dan Walsh not cringe that much. The patch series invokes docker from the Makefile and the CI systems we are targetting with this also use docker, so it is not wrong to refer to docker. Furthermore everyone knows what you mean when you refer to docker, while only a subset of people will have any idea what podman is. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Apr 03, 2019 at 01:34:04PM +0100, Daniel P. Berrangé wrote: >On Wed, Apr 03, 2019 at 02:29:55PM +0200, Martin Kletzander wrote: >> On Wed, Apr 03, 2019 at 11:41:41AM +0100, Daniel P. Berrangé wrote: >> > For a while QEMU has provided simple make rules for building QEMU inside >> > standard docker container environments. This provides an equivalent >> > mechanism for libvirt inspired by QEMU's. >> > >> >> Can we change this so that we don't mention docker everywhere? These are just >> containers and you can run them using other tools with no docker dependency. I >> know I can set an alias docker=podman and it will just work, but now that >> podman, buildah, skopeo and others work on my machine (even non-systemd one) I >> think it would be nice stop requiring "docker" if it is not needed. And to make >> Dan Walsh not cringe that much. > >The patch series invokes docker from the Makefile and the CI systems we >are targetting with this also use docker, so it is not wrong to refer to >docker. Furthermore everyone knows what you mean when you refer to docker, >while only a subset of people will have any idea what podman is. > I'm suggesting s/docker containers/containers/ in commit messages and comments and maybe (but I can add that later) testing whether you have at least one of docker/podman installed in the makefile and using that instead of hardcoding the "docker" string in there. Feel free to ignore my suggestion, I just thought it would be nice if we were a bit more inclusive instead of using proprietary eponyms. >Regards, >Daniel >-- >|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| >|: https://libvirt.org -o- https://fstop138.berrange.com :| >|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, 2019-04-03 at 14:43 +0200, Martin Kletzander wrote: > On Wed, Apr 03, 2019 at 01:34:04PM +0100, Daniel P. Berrangé wrote: > > On Wed, Apr 03, 2019 at 02:29:55PM +0200, Martin Kletzander wrote: > > > On Wed, Apr 03, 2019 at 11:41:41AM +0100, Daniel P. Berrangé wrote: > > > > For a while QEMU has provided simple make rules for building QEMU inside > > > > standard docker container environments. This provides an equivalent > > > > mechanism for libvirt inspired by QEMU's. > > > > > > Can we change this so that we don't mention docker everywhere? These are just > > > containers and you can run them using other tools with no docker dependency. I > > > know I can set an alias docker=podman and it will just work, but now that > > > podman, buildah, skopeo and others work on my machine (even non-systemd one) I > > > think it would be nice stop requiring "docker" if it is not needed. And to make > > > Dan Walsh not cringe that much. > > > > The patch series invokes docker from the Makefile and the CI systems we > > are targetting with this also use docker, so it is not wrong to refer to > > docker. Furthermore everyone knows what you mean when you refer to docker, > > while only a subset of people will have any idea what podman is. > > I'm suggesting s/docker containers/containers/ in commit messages and comments > and maybe (but I can add that later) testing whether you have at least one of > docker/podman installed in the makefile and using that instead of hardcoding the > "docker" string in there. Feel free to ignore my suggestion, I just thought it > would be nice if we were a bit more inclusive instead of using proprietary > eponyms. FWIW I've already tried swapping Docker for Podman and it doesn't quite work yet. Once the current incarnation has been merged, I plan to figure out how to make it work with unpriviledged Podman containers (I'd rather not run priviledged containers on my machine) and along with that I'll also replace references to Dockers with the generic equivalent where it makes sense. As it is now, this only works with Docker so mentioning it seems perfectly reasonable :) -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2024 Red Hat, Inc.