[libvirt] [PATCH jenkins-ci 00/19] Use jenkins-job-builder for CI
We are using the CentOS Jenkins server for running CI tasks. Currently those tasks are maintained by people manually updating the Jenkins web UI. This is a horrible interface that requires 100's of mouse clicks to achieve even the simplest things. It is also incredibly hard to compare the config of different jobs to make sure they are working in a consistent manner. Fortunately there are tools which can help - OpenStack created the jenkins-job-builder tool which uses the Jenkins REST API to create/update jobs from a simple YAML file definition. This series thus creates a set of YAML files which will (almost) replicate our current manually create config. I've used jenkins-job-builder in offline test mode to generate Jenkins XML files and then compared them to what we currently have and they are mostly the same. So there should not be too many suprises lurking, but I do still expect some accidental breakage in places. As such I have not actually uploaded the new auto-generated job configs to ci.centos.org at this time. The intention is that these configs will all live in the libvirt GIT server in a new 'libvirt-jenkins-ci' repository Daniel P. Berrange (19): jobs: add global default variables jobs: add a template for generic build process jobs: add a template for GNU autotools jobs: add a template for Python distutils jobs: add a template for Perl ExtUtils::MakeMaker jobs: add a template for Perl Module::Build projects: add the libvirt package projects: add the libvirt-python package projects: add the libvirt-perl package projects: add the libvirt-tck package projects: add the libvirt-glib package projects: add the libvirt-sandbox package projects: add the osinfo-db-tools package projects: add the osinfo-db package projects: add the libvirt-cim package projects: add the virt-viewer package projects: add the virt-manager package projects: add the libosinfo package Add README explaining how to use it README | 34 ++++++++ jobs/autotools.yaml | 198 ++++++++++++++++++++++++++++++++++++++++++ jobs/defaults.yaml | 11 +++ jobs/generic.yaml | 124 ++++++++++++++++++++++++++ jobs/perl-makemaker.yaml | 105 ++++++++++++++++++++++ jobs/perl-modulebuild.yaml | 104 ++++++++++++++++++++++ jobs/python-distutils.yaml | 99 +++++++++++++++++++++ projects/libosinfo.yaml | 20 +++++ projects/libvirt-cim.yaml | 24 +++++ projects/libvirt-glib.yaml | 20 +++++ projects/libvirt-perl.yaml | 18 ++++ projects/libvirt-python.yaml | 18 ++++ projects/libvirt-sandbox.yaml | 19 ++++ projects/libvirt-tck.yaml | 16 ++++ projects/libvirt.yaml | 44 ++++++++++ projects/osinfo-db-tools.yaml | 19 ++++ projects/osinfo-db.yaml | 24 +++++ projects/virt-manager.yaml | 19 ++++ projects/virt-viewer.yaml | 19 ++++ 19 files changed, 935 insertions(+) create mode 100644 README create mode 100644 jobs/autotools.yaml create mode 100644 jobs/defaults.yaml create mode 100644 jobs/generic.yaml create mode 100644 jobs/perl-makemaker.yaml create mode 100644 jobs/perl-modulebuild.yaml create mode 100644 jobs/python-distutils.yaml create mode 100644 projects/libosinfo.yaml create mode 100644 projects/libvirt-cim.yaml create mode 100644 projects/libvirt-glib.yaml create mode 100644 projects/libvirt-perl.yaml create mode 100644 projects/libvirt-python.yaml create mode 100644 projects/libvirt-sandbox.yaml create mode 100644 projects/libvirt-tck.yaml create mode 100644 projects/libvirt.yaml create mode 100644 projects/osinfo-db-tools.yaml create mode 100644 projects/osinfo-db.yaml create mode 100644 projects/virt-manager.yaml create mode 100644 projects/virt-viewer.yaml -- 2.7.4
Add some global default variable definitions Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- jobs/defaults.yaml | 11 +++++++++++ 1 file changed, 11 insertions(+) create mode 100644 jobs/defaults.yaml diff --git a/jobs/defaults.yaml b/jobs/defaults.yaml new file mode 100644 index 0000000..b7b3708 --- /dev/null +++ b/jobs/defaults.yaml @@ -0,0 +1,11 @@ + +- defaults: + name: global + make_env: | + MAKE='make' + unamestr=`uname` + if [ "$unamestr" = 'FreeBSD' ]; then + MAKE='gmake' + fi + smp: 3 + spam: shajyan@redhat.com libvirt-ci@redhat.com -- 2.7.4
Add a template for projects which don't fit into any of the special purpose templates. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- jobs/generic.yaml | 124 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 124 insertions(+) create mode 100644 jobs/generic.yaml diff --git a/jobs/generic.yaml b/jobs/generic.yaml new file mode 100644 index 0000000..12de76a --- /dev/null +++ b/jobs/generic.yaml @@ -0,0 +1,124 @@ + +- job-template: + id: generic-build-job + name: '{name}-build' + project-type: matrix + description: '{title} Build' + autogen_args: '' + workspace: '{name}' + block-downstream: true + block-upstream: true + properties: + - build-discarder: + days-to-keep: 30 + num-to-keep: 1000 + scm: + - git: + url: git://n64.pufty.ci.centos.org/{name}.git + branches: + - origin/master + clean: true + triggers: + - reverse: + jobs: '{obj:parent_jobs}' + - pollscm: + cron: "H/20 * * * *" + axes: + - axis: + name: systems + type: slave + values: '{obj:machines}' + builders: + - shell: '{command}' + publishers: + - email: + recipients: '{obj:spam}' + notify-every-unstable-build: true + send-to-individuals: false + +- job-template: + id: generic-syntax-check-job + name: '{name}-syntax-check' + project-type: matrix + description: '{title} Syntax Check' + workspace: '{name}' + block-downstream: true + block-upstream: true + properties: + - build-discarder: + days-to-keep: 30 + num-to-keep: 1000 + triggers: + - reverse: + jobs: '{obj:parent_jobs}' + axes: + - axis: + name: systems + type: slave + values: '{obj:machines}' + builders: + - shell: '{command}' + publishers: + - email: + recipients: '{obj:spam}' + notify-every-unstable-build: true + send-to-individuals: false + +- job-template: + id: generic-check-job + name: '{name}-check' + project-type: matrix + description: '{title} Check' + workspace: '{name}' + block-downstream: true + block-upstream: true + properties: + - build-discarder: + days-to-keep: 30 + num-to-keep: 1000 + triggers: + - reverse: + jobs: '{obj:parent_jobs}' + axes: + - axis: + name: systems + type: slave + values: '{obj:machines}' + builders: + - shell: | + cd build + make -j{smp} check + publishers: + - email: + recipients: '{obj:spam}' + notify-every-unstable-build: true + send-to-individuals: false + +- job-template: + id: generic-rpm-job + name: '{name}-rpm' + project-type: matrix + description: '{title} RPM' + archive_format: gz + workspace: '{name}' + block-downstream: true + block-upstream: true + properties: + - build-discarder: + days-to-keep: 30 + num-to-keep: 1000 + triggers: + - reverse: + jobs: '{obj:parent_jobs}' + axes: + - axis: + name: systems + type: slave + values: '{obj:machines}' + builders: + - shell: '{command}' + publishers: + - email: + recipients: '{obj:spam}' + notify-every-unstable-build: true + send-to-individuals: false -- 2.7.4
On Thu, Aug 04, 2016 at 03:52:11PM +0100, Daniel P. Berrange wrote:
Add a template for projects which don't fit into any of the special purpose templates.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- jobs/generic.yaml | 124 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 124 insertions(+) create mode 100644 jobs/generic.yaml
diff --git a/jobs/generic.yaml b/jobs/generic.yaml new file mode 100644 index 0000000..12de76a --- /dev/null +++ b/jobs/generic.yaml @@ -0,0 +1,124 @@
[...]
+- job-template: + id: generic-check-job + name: '{name}-check' + project-type: matrix + description: '{title} Check' + workspace: '{name}' + block-downstream: true + block-upstream: true + properties: + - build-discarder: + days-to-keep: 30 + num-to-keep: 1000 + triggers: + - reverse: + jobs: '{obj:parent_jobs}' + axes: + - axis: + name: systems + type: slave + values: '{obj:machines}' + builders: + - shell: | + cd build + make -j{smp} check
This should be also "- shell: '{command}'"
+ publishers: + - email: + recipients: '{obj:spam}' + notify-every-unstable-build: true + send-to-individuals: false
Add a template for projects using the GNU autotools framework --- jobs/autotools.yaml | 198 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 198 insertions(+) create mode 100644 jobs/autotools.yaml diff --git a/jobs/autotools.yaml b/jobs/autotools.yaml new file mode 100644 index 0000000..652d4cd --- /dev/null +++ b/jobs/autotools.yaml @@ -0,0 +1,198 @@ + +- job-template: + id: autotools-build-job + name: '{name}-build' + project-type: matrix + description: '{title} Build' + autogen_args: '' + workspace: '{name}' + block-downstream: true + block-upstream: true + properties: + - build-discarder: + days-to-keep: 30 + num-to-keep: 1000 + scm: + - git: + url: git://n64.pufty.ci.centos.org/{name}.git + branches: + - origin/master + clean: true + triggers: + - reverse: + jobs: '{obj:parent_jobs}' + - pollscm: + cron: "H/20 * * * *" + axes: + - axis: + name: systems + type: slave + values: '{obj:machines}' + builders: + - shell: | + {make_env} + mkdir build + cd build + ../autogen.sh --prefix=$VIRT_PREFIX {autogen_args} + $MAKE -j{smp} + $MAKE -j{smp} install + publishers: + - email: + recipients: '{obj:spam}' + notify-every-unstable-build: true + send-to-individuals: false + +- job-template: + id: autotools-syntax-check-job + name: '{name}-syntax-check' + project-type: matrix + description: '{title} Syntax Check' + workspace: '{name}' + block-downstream: true + block-upstream: true + properties: + - build-discarder: + days-to-keep: 30 + num-to-keep: 1000 + triggers: + - reverse: + jobs: '{obj:parent_jobs}' + axes: + - axis: + name: systems + type: slave + values: '{obj:machines}' + builders: + - shell: | + {make_env} + cd build + $MAKE -j{smp} syntax-check + publishers: + - email: + recipients: '{obj:spam}' + notify-every-unstable-build: true + send-to-individuals: false + +- job-template: + id: autotools-check-job + name: '{name}-check' + project-type: matrix + description: '{title} Check' + check_env: '' + workspace: '{name}' + block-downstream: true + block-upstream: true + properties: + - build-discarder: + days-to-keep: 30 + num-to-keep: 1000 + triggers: + - reverse: + jobs: '{obj:parent_jobs}' + axes: + - axis: + name: systems + type: slave + values: '{obj:machines}' + builders: + - shell: | + {make_env} + {check_env} + cd build + $MAKE -j{smp} check + publishers: + - email: + recipients: '{obj:spam}' + notify-every-unstable-build: true + send-to-individuals: false + +- job-template: + id: autotools-rpm-job + name: '{name}-rpm' + project-type: matrix + description: '{title} RPM' + archive_format: gz + workspace: '{name}' + block-downstream: true + block-upstream: true + properties: + - build-discarder: + days-to-keep: 30 + num-to-keep: 1000 + triggers: + - reverse: + jobs: '{obj:parent_jobs}' + axes: + - axis: + name: systems + type: slave + values: '{obj:machines}' + builders: + - shell: | + {make_env} + cd build + sed -i -e 's/BuildRequires: libvirt.*devel.*//' {name}.spec + rm -f *.tar.{archive_format} + $MAKE -j{smp} dist + rpmbuild -ta {name}-*.tar.{archive_format} + publishers: + - email: + recipients: '{obj:spam}' + notify-every-unstable-build: true + send-to-individuals: false + +- job-template: + id: autotools-mingw-job + name: '{name}-mingw' + project-type: matrix + description: '{title} MinGW' + autogen_args: '' + workspace: '{name}-mingw' + block-downstream: true + block-upstream: true + properties: + - build-discarder: + days-to-keep: 30 + num-to-keep: 1000 + scm: + - git: + url: git://n64.pufty.ci.centos.org/{name}.git + branches: + - origin/master + clean: true + triggers: + - reverse: + jobs: '{obj:parent_jobs}' + - pollscm: + cron: "H/20 * * * *" + axes: + - axis: + name: systems + type: slave + values: '{obj:machines}' + builders: + - shell: | + mkdir -p build32 + cd build32 + + export PKG_CONFIG_LIBDIR="/usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig:/usr/x86_64-w64-mingw32/sys-root/mingw/share/pkgconfig" + export PKG_CONFIG_PATH="$VIRT_PREFIX/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig" \ + export PREFIX=$VIRT_PREFIX/x86_64-w64-mingw32/sys-root/mingw + ../autogen.sh --host=i686-w64-mingw32 --prefix=$PREFIX + make -j{smp} + make -j{smp} install + - shell: | + mkdir -p build64 + cd build64 + + export PKG_CONFIG_LIBDIR="/usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig:/usr/x86_64-w64-mingw32/sys-root/mingw/share/pkgconfig" + export PKG_CONFIG_PATH="$VIRT_PREFIX/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig" \ + export PREFIX=$VIRT_PREFIX/x86_64-w64-mingw32/sys-root/mingw + ../autogen.sh --host=x86_64-w64-mingw32 --prefix=$PREFIX + make -j{smp} + make -j{smp} install + publishers: + - email: + recipients: '{obj:spam}' + notify-every-unstable-build: true + send-to-individuals: false -- 2.7.4
Add a template for projects using the python distutils framework Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- jobs/python-distutils.yaml | 99 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 jobs/python-distutils.yaml diff --git a/jobs/python-distutils.yaml b/jobs/python-distutils.yaml new file mode 100644 index 0000000..6179d3f --- /dev/null +++ b/jobs/python-distutils.yaml @@ -0,0 +1,99 @@ + +- job-template: + id: python-distutils-build-job + name: '{name}-build' + project-type: matrix + description: '{title} Build' + autogen_args: '' + workspace: '{name}' + block-downstream: true + block-upstream: true + properties: + - build-discarder: + days-to-keep: 30 + num-to-keep: 1000 + scm: + - git: + url: git://n64.pufty.ci.centos.org/{name}.git + branches: + - origin/master + clean: true + triggers: + - reverse: + jobs: '{obj:parent_jobs}' + - pollscm: + cron: "H/20 * * * *" + axes: + - axis: + name: systems + type: slave + values: '{obj:machines}' + builders: + - shell: | + python setup.py build + python setup.py install --prefix=$VIRT_PREFIX + publishers: + - email: + recipients: '{obj:spam}' + notify-every-unstable-build: true + send-to-individuals: false + + +- job-template: + id: python-distutils-check-job + name: '{name}-check' + project-type: matrix + description: '{title} Check' + workspace: '{name}' + block-downstream: true + block-upstream: true + properties: + - build-discarder: + days-to-keep: 30 + num-to-keep: 1000 + triggers: + - reverse: + jobs: '{obj:parent_jobs}' + axes: + - axis: + name: systems + type: slave + values: '{obj:machines}' + builders: + - shell: | + python setup.py test + publishers: + - email: + recipients: '{obj:spam}' + notify-every-unstable-build: true + send-to-individuals: false + +- job-template: + id: python-distutils-rpm-job + name: '{name}-rpm' + project-type: matrix + description: '{title} RPM' + workspace: '{name}' + block-downstream: true + block-upstream: true + properties: + - build-discarder: + days-to-keep: 30 + num-to-keep: 1000 + triggers: + - reverse: + jobs: '{obj:parent_jobs}' + axes: + - axis: + name: systems + type: slave + values: '{obj:machines}' + builders: + - shell: | + sed -i -e 's/BuildRequires: libvirt.*devel.*//' *.spec + python setup.py rpm + publishers: + - email: + recipients: '{obj:spam}' + notify-every-unstable-build: true + send-to-individuals: false -- 2.7.4
Add a template for projects using the Perl ExtUtils::MakeMaker setup Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- jobs/perl-makemaker.yaml | 105 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 105 insertions(+) create mode 100644 jobs/perl-makemaker.yaml diff --git a/jobs/perl-makemaker.yaml b/jobs/perl-makemaker.yaml new file mode 100644 index 0000000..a6b5215 --- /dev/null +++ b/jobs/perl-makemaker.yaml @@ -0,0 +1,105 @@ + +- job-template: + id: perl-makemaker-build-job + name: '{name}-build' + project-type: matrix + description: '{title} Build' + autogen_args: '' + workspace: '{name}' + block-downstream: true + block-upstream: true + properties: + - build-discarder: + days-to-keep: 30 + num-to-keep: 1000 + scm: + - git: + url: git://n64.pufty.ci.centos.org/{name}.git + branches: + - origin/master + clean: true + triggers: + - reverse: + jobs: '{obj:parent_jobs}' + - pollscm: + cron: "H/20 * * * *" + axes: + - axis: + name: systems + type: slave + values: '{obj:machines}' + builders: + - shell: | + perl Makefile.PL PREFIX="$VIRT_PREFIX" + make -j{smp} + make -j{smp} install + make -j{smp} manifest + publishers: + - email: + recipients: '{obj:spam}' + notify-every-unstable-build: true + send-to-individuals: false + + +- job-template: + id: perl-makemaker-test-job + name: '{name}-test' + project-type: matrix + description: '{title} Test' + test_args: '' + workspace: '{name}' + block-downstream: true + block-upstream: true + properties: + - build-discarder: + days-to-keep: 30 + num-to-keep: 1000 + triggers: + - reverse: + jobs: '{obj:parent_jobs}' + axes: + - axis: + name: systems + type: slave + values: '{obj:machines}' + builders: + - shell: | + make -j{smp} test {test_args} + publishers: + - email: + recipients: '{obj:spam}' + notify-every-unstable-build: true + send-to-individuals: false + +- job-template: + id: perl-makemaker-rpm-job + name: '{name}-rpm' + project-type: matrix + description: '{title} RPM' + archive_format: gz + workspace: '{name}' + block-downstream: true + block-upstream: true + properties: + - build-discarder: + days-to-keep: 30 + num-to-keep: 1000 + triggers: + - reverse: + jobs: '{obj:parent_jobs}' + axes: + - axis: + name: systems + type: slave + values: '{obj:machines}' + builders: + - shell: | + sed -i -e 's/BuildRequires: libvirt.*devel.*//' *.spec + rm -f *.tar.{archive_format} + make -j{smp} dist + rpmbuild -ta *.tar.{archive_format} + publishers: + - email: + recipients: '{obj:spam}' + notify-every-unstable-build: true + send-to-individuals: false -- 2.7.4
Add a template for projects using the Perl Module::Build framework Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- jobs/perl-modulebuild.yaml | 104 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 104 insertions(+) create mode 100644 jobs/perl-modulebuild.yaml diff --git a/jobs/perl-modulebuild.yaml b/jobs/perl-modulebuild.yaml new file mode 100644 index 0000000..acef9e2 --- /dev/null +++ b/jobs/perl-modulebuild.yaml @@ -0,0 +1,104 @@ + +- job-template: + id: perl-modulebuild-build-job + name: '{name}-build' + project-type: matrix + description: '{title} Build' + autogen_args: '' + workspace: '{name}' + block-downstream: true + block-upstream: true + properties: + - build-discarder: + days-to-keep: 30 + num-to-keep: 1000 + scm: + - git: + url: git://n64.pufty.ci.centos.org/{name}.git + branches: + - origin/master + clean: true + triggers: + - reverse: + jobs: '{obj:parent_jobs}' + - pollscm: + cron: "H/20 * * * *" + axes: + - axis: + name: systems + type: slave + values: '{obj:machines}' + builders: + - shell: | + perl Build.PL install_base="$VIRT_PREFIX" + perl Build manifest + perl Build + perl Build install + publishers: + - email: + recipients: '{obj:spam}' + notify-every-unstable-build: true + send-to-individuals: false + + +- job-template: + id: perl-modulebuild-test-job + name: '{name}-test' + project-type: matrix + description: '{title} Test' + workspace: '{name}' + block-downstream: true + block-upstream: true + properties: + - build-discarder: + days-to-keep: 30 + num-to-keep: 1000 + triggers: + - reverse: + jobs: '{obj:parent_jobs}' + axes: + - axis: + name: systems + type: slave + values: '{obj:machines}' + builders: + - shell: | + perl Build test + publishers: + - email: + recipients: '{obj:spam}' + notify-every-unstable-build: true + send-to-individuals: false + +- job-template: + id: perl-modulebuild-rpm-job + name: '{name}-rpm' + project-type: matrix + description: '{title} RPM' + archive_format: gz + workspace: '{name}' + block-downstream: true + block-upstream: true + properties: + - build-discarder: + days-to-keep: 30 + num-to-keep: 1000 + triggers: + - reverse: + jobs: '{obj:parent_jobs}' + axes: + - axis: + name: systems + type: slave + values: '{obj:machines}' + builders: + - shell: | + sed -i -e 's/BuildRequires: perl-Sys-Virt.*//' *.spec + rm -f *.tar.{archive_format} + perl Build dist + rpmbuild -ta *.tar.{archive_format} + publishers: + - email: + recipients: '{obj:spam}' + notify-every-unstable-build: true + send-to-individuals: false -- 2.7.4
Add a project defining the libvirt package build jobs Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- projects/libvirt.yaml | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 projects/libvirt.yaml diff --git a/projects/libvirt.yaml b/projects/libvirt.yaml new file mode 100644 index 0000000..17c05c6 --- /dev/null +++ b/projects/libvirt.yaml @@ -0,0 +1,44 @@ + +- project: + name: libvirt + machines: + - libvirt-centos-6 + - libvirt-centos-7 + - libvirt-fedora-21 + - libvirt-fedora-22 + - libvirt-fedora-23 + - libvirt-fedora-rawhide + title: Libvirt + jobs: + - autotools-build-job: + parent_jobs: + machines: + - libvirt-centos-6 + - libvirt-centos-7 + - libvirt-debian + - libvirt-fedora-21 + - libvirt-fedora-22 + - libvirt-fedora-23 + - libvirt-fedora-rawhide + - libvirt-freebsd + - autotools-syntax-check-job: + parent_jobs: 'libvirt-build' + machines: + - libvirt-centos-6 + - libvirt-centos-7 + - libvirt-debian + - libvirt-fedora-21 + - libvirt-fedora-22 + - libvirt-fedora-23 + - libvirt-fedora-rawhide + check_env: | + export VIR_TEST_EXPENSIVE=1 + export VIR_TEST_DEBUG=2 + - autotools-check-job: + parent_jobs: 'libvirt-syntax-check' + - autotools-rpm-job: + parent_jobs: 'libvirt-check' + - autotools-mingw-job: + parent_jobs: + machines: + - libvirt-fedora-rawhide -- 2.7.4
Add a project defining the libvirt-python package build jobs Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- projects/libvirt-python.yaml | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 projects/libvirt-python.yaml diff --git a/projects/libvirt-python.yaml b/projects/libvirt-python.yaml new file mode 100644 index 0000000..4c596c5 --- /dev/null +++ b/projects/libvirt-python.yaml @@ -0,0 +1,18 @@ + +- project: + name: libvirt-python + machines: + - libvirt-centos-6 + - libvirt-centos-7 + - libvirt-fedora-21 + - libvirt-fedora-22 + - libvirt-fedora-23 + - libvirt-fedora-rawhide + title: Libvirt Python + jobs: + - python-distutils-build-job: + parent_jobs: 'libvirt-build' + - python-distutils-check-job: + parent_jobs: 'libvirt-python-build' + - python-distutils-rpm-job: + parent_jobs: 'libvirt-python-check' -- 2.7.4
Add a project defining the libvirt-perl package build jobs Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- projects/libvirt-perl.yaml | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 projects/libvirt-perl.yaml diff --git a/projects/libvirt-perl.yaml b/projects/libvirt-perl.yaml new file mode 100644 index 0000000..8756dd5 --- /dev/null +++ b/projects/libvirt-perl.yaml @@ -0,0 +1,18 @@ + +- project: + name: libvirt-perl + machines: + - libvirt-centos-7 + - libvirt-fedora-21 + - libvirt-fedora-22 + - libvirt-fedora-23 + - libvirt-fedora-rawhide + title: Libvirt Perl + jobs: + - perl-makemaker-build-job: + parent_jobs: 'libvirt-build' + - perl-makemaker-test-job: + parent_jobs: 'libvirt-perl-build' + test_args: 'TEST_MAINTAINER=1' + - perl-makemaker-rpm-job: + parent_jobs: 'libvirt-perl-test' -- 2.7.4
Add a project defining the libvirt-tck package build jobs Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- projects/libvirt-tck.yaml | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 projects/libvirt-tck.yaml diff --git a/projects/libvirt-tck.yaml b/projects/libvirt-tck.yaml new file mode 100644 index 0000000..efa4815 --- /dev/null +++ b/projects/libvirt-tck.yaml @@ -0,0 +1,16 @@ + +- project: + name: libvirt-tck + machines: + - libvirt-fedora-21 + - libvirt-fedora-22 + - libvirt-fedora-23 + - libvirt-fedora-rawhide + title: Libvirt TCK + jobs: + - perl-modulebuild-build-job: + parent_jobs: 'libvirt-perl-build' + - perl-modulebuild-test-job: + parent_jobs: 'libvirt-tck-build' + - perl-modulebuild-rpm-job: + parent_jobs: 'libvirt-tck-test' -- 2.7.4
Add a project defining the libvirt-glib package build jobs Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- projects/libvirt-glib.yaml | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 projects/libvirt-glib.yaml diff --git a/projects/libvirt-glib.yaml b/projects/libvirt-glib.yaml new file mode 100644 index 0000000..73c31e1 --- /dev/null +++ b/projects/libvirt-glib.yaml @@ -0,0 +1,20 @@ + +- project: + name: libvirt-glib + machines: + - libvirt-centos-7 + - libvirt-fedora-21 + - libvirt-fedora-22 + - libvirt-fedora-23 + - libvirt-fedora-rawhide + title: Libvirt GLib + jobs: + - autotools-build-job: + parent_jobs: 'libvirt-build' + autogen_args: --enable-gtk-doc + - autotools-syntax-check-job: + parent_jobs: 'libvirt-glib-build' + - autotools-check-job: + parent_jobs: 'libvirt-glib-syntax-check' + - autotools-rpm-job: + parent_jobs: 'libvirt-glib-check' -- 2.7.4
Add a project defining the libvirt-sandbox package build jobs Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- projects/libvirt-sandbox.yaml | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 projects/libvirt-sandbox.yaml diff --git a/projects/libvirt-sandbox.yaml b/projects/libvirt-sandbox.yaml new file mode 100644 index 0000000..81ac632 --- /dev/null +++ b/projects/libvirt-sandbox.yaml @@ -0,0 +1,19 @@ + +- project: + name: libvirt-sandbox + machines: + - libvirt-fedora-21 + - libvirt-fedora-22 + - libvirt-fedora-23 + - libvirt-fedora-rawhide + title: Libvirt Sandbox + jobs: + - autotools-build-job: + parent_jobs: 'libvirt-glib-build' + autogen_args: --enable-gtk-doc + - autotools-syntax-check-job: + parent_jobs: 'libvirt-sandbox-build' + - autotools-check-job: + parent_jobs: 'libvirt-sandbox-syntax-check' + - autotools-rpm-job: + parent_jobs: 'libvirt-sandbox-check' -- 2.7.4
Add a project defining the osinfo-db-tools package build jobs Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- projects/osinfo-db-tools.yaml | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 projects/osinfo-db-tools.yaml diff --git a/projects/osinfo-db-tools.yaml b/projects/osinfo-db-tools.yaml new file mode 100644 index 0000000..5813c1a --- /dev/null +++ b/projects/osinfo-db-tools.yaml @@ -0,0 +1,19 @@ + +- project: + name: osinfo-db-tools + machines: + - libvirt-centos-7 + - libvirt-fedora-21 + - libvirt-fedora-22 + - libvirt-fedora-23 + - libvirt-fedora-rawhide + title: osinfo database tools + jobs: + - autotools-build-job: + parent_jobs: + - autotools-syntax-check-job: + parent_jobs: 'osinfo-db-tools-build' + - autotools-check-job: + parent_jobs: 'osinfo-db-tools-syntax-check' + - autotools-rpm-job: + parent_jobs: 'osinfo-db-tools-check' -- 2.7.4
Add a project defining the osinfo-db package build jobs Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- projects/osinfo-db.yaml | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 projects/osinfo-db.yaml diff --git a/projects/osinfo-db.yaml b/projects/osinfo-db.yaml new file mode 100644 index 0000000..17f1e45 --- /dev/null +++ b/projects/osinfo-db.yaml @@ -0,0 +1,24 @@ + +- project: + name: osinfo-db + machines: + - libvirt-centos-7 + - libvirt-fedora-21 + - libvirt-fedora-22 + - libvirt-fedora-23 + - libvirt-fedora-rawhide + title: osinfo database + jobs: + - generic-build-job: + parent_jobs: 'osinfo-db-tools-build' + command: | + export PATH=$VIRT_PREFIX/bin:$PATH + make -j3 all + make install OSINFO_DB_TARGET="--system" + - generic-rpm-job: + parent_jobs: 'osinfo-db-build' + command: | + rm -f *.tar.xz + make osinfo-db.spec + perl -i -p -e 's/BuildRequires: osinfo-db-tools.*//' osinfo-db.spec + make rpm -- 2.7.4
Add a project defining the libvirt-cim package build jobs Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- projects/libvirt-cim.yaml | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 projects/libvirt-cim.yaml diff --git a/projects/libvirt-cim.yaml b/projects/libvirt-cim.yaml new file mode 100644 index 0000000..af86e6e --- /dev/null +++ b/projects/libvirt-cim.yaml @@ -0,0 +1,24 @@ + +- project: + name: libvirt-cim + machines: + - libvirt-centos-6 + - libvirt-centos-7 + - libvirt-fedora-21 + - libvirt-fedora-22 + - libvirt-fedora-23 + - libvirt-fedora-rawhide + title: libvirt CIM + jobs: + - generic-build-job: + parent_jobs: 'libvirt-build' + command: | + ./autoconfiscate.sh + ./configure --prefix=$VIRT_PREFIX + make -j{smp} + make -j{smp} install + - generic-rpm-job: + parent_jobs: 'libvirt-cim-build' + command: | + sed -i -e "s/.*libvirt-devel.*//" libvirt-cim.spec.in + make -j{smp} rpm -- 2.7.4
Add a project defining the virt-viewer package build jobs Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- projects/virt-viewer.yaml | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 projects/virt-viewer.yaml diff --git a/projects/virt-viewer.yaml b/projects/virt-viewer.yaml new file mode 100644 index 0000000..15eb0ed --- /dev/null +++ b/projects/virt-viewer.yaml @@ -0,0 +1,19 @@ + +- project: + name: virt-viewer + machines: + - libvirt-centos-7 + - libvirt-fedora-21 + - libvirt-fedora-22 + - libvirt-fedora-23 + - libvirt-fedora-rawhide + title: Virt Viewer GLib + jobs: + - autotools-build-job: + parent_jobs: 'libvirt-glib-build' + - autotools-syntax-check-job: + parent_jobs: 'virt-viewer-build' + - autotools-check-job: + parent_jobs: 'virt-viewer-syntax-check' + - autotools-rpm-job: + parent_jobs: 'virt-viewer-check' -- 2.7.4
On Thu, 2016-08-04 at 15:52 +0100, Daniel P. Berrange wrote:
Add a project defining the virt-viewer package build jobs  Signed-off-by: Daniel P. Berrange <berrange@redhat.com> ---   projects/virt-viewer.yaml | 19 +++++++++++++++++++   1 file changed, 19 insertions(+)   create mode 100644 projects/virt-viewer.yaml  diff --git a/projects/virt-viewer.yaml b/projects/virt-viewer.yaml new file mode 100644 index 0000000..15eb0ed --- /dev/null +++ b/projects/virt-viewer.yaml @@ -0,0 +1,19 @@ + +- project: +    name: virt-viewer +    machines: +      - libvirt-centos-7 +      - libvirt-fedora-21 +      - libvirt-fedora-22 +      - libvirt-fedora-23 +      - libvirt-fedora-rawhide +    title: Virt Viewer GLib
s/ GLib$//
+Â Â Â Â jobs: +Â Â Â Â Â Â - autotools-build-job: +Â Â Â Â Â Â Â Â Â Â parent_jobs: 'libvirt-glib-build' +Â Â Â Â Â Â - autotools-syntax-check-job: +Â Â Â Â Â Â Â Â Â Â parent_jobs: 'virt-viewer-build' +Â Â Â Â Â Â - autotools-check-job: +Â Â Â Â Â Â Â Â Â Â parent_jobs: 'virt-viewer-syntax-check' +Â Â Â Â Â Â - autotools-rpm-job: +Â Â Â Â Â Â Â Â Â Â parent_jobs: 'virt-viewer-check'
--Â Andrea Bolognani / Red Hat / Virtualization
Add a project defining the virt-manager package build jobs Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- projects/virt-manager.yaml | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 projects/virt-manager.yaml diff --git a/projects/virt-manager.yaml b/projects/virt-manager.yaml new file mode 100644 index 0000000..101a76c --- /dev/null +++ b/projects/virt-manager.yaml @@ -0,0 +1,19 @@ + +- project: + name: virt-manager + machines: + - libvirt-centos-7 + - libvirt-fedora-21 + - libvirt-fedora-22 + - libvirt-fedora-23 + - libvirt-fedora-rawhide + title: Libvirt Python + jobs: + - python-distutils-build-job: + parent_jobs: + - 'libvirt-python-build' + - 'libosinfo-build' + - python-distutils-check-job: + parent_jobs: 'virt-manager-build' + - python-distutils-rpm-job: + parent_jobs: 'virt-manager-check' -- 2.7.4
On Thu, 2016-08-04 at 15:52 +0100, Daniel P. Berrange wrote:
Add a project defining the virt-manager package build jobs  Signed-off-by: Daniel P. Berrange <berrange@redhat.com> ---   projects/virt-manager.yaml | 19 +++++++++++++++++++   1 file changed, 19 insertions(+)   create mode 100644 projects/virt-manager.yaml  diff --git a/projects/virt-manager.yaml b/projects/virt-manager.yaml new file mode 100644 index 0000000..101a76c --- /dev/null +++ b/projects/virt-manager.yaml @@ -0,0 +1,19 @@ + +- project: +    name: virt-manager +    machines: +      - libvirt-centos-7 +      - libvirt-fedora-21 +      - libvirt-fedora-22 +      - libvirt-fedora-23 +      - libvirt-fedora-rawhide +    title: Libvirt Python
s/Libvirt Python/Virt Manager/
+Â Â Â Â jobs: +Â Â Â Â Â Â - python-distutils-build-job: +Â Â Â Â Â Â Â Â Â Â parent_jobs: +Â Â Â Â Â Â Â Â Â Â Â Â - 'libvirt-python-build' +Â Â Â Â Â Â Â Â Â Â Â Â - 'libosinfo-build' +Â Â Â Â Â Â - python-distutils-check-job: +Â Â Â Â Â Â Â Â Â Â parent_jobs: 'virt-manager-build' +Â Â Â Â Â Â - python-distutils-rpm-job: +Â Â Â Â Â Â Â Â Â Â parent_jobs: 'virt-manager-check'
--Â Andrea Bolognani / Red Hat / Virtualization
On Thu, 2016-08-04 at 15:52 +0100, Daniel P. Berrange wrote:
Add a project defining the virt-manager package build jobs  Signed-off-by: Daniel P. Berrange <berrange@redhat.com> ---   projects/virt-manager.yaml | 19 +++++++++++++++++++   1 file changed, 19 insertions(+)   create mode 100644 projects/virt-manager.yaml  diff --git a/projects/virt-manager.yaml b/projects/virt-manager.yaml new file mode 100644 index 0000000..101a76c --- /dev/null +++ b/projects/virt-manager.yaml @@ -0,0 +1,19 @@ + +- project: +    name: virt-manager +    machines: +      - libvirt-centos-7 +      - libvirt-fedora-21 +      - libvirt-fedora-22 +      - libvirt-fedora-23 +      - libvirt-fedora-rawhide
I'm using virt-manager as an example here, but the question actually applies to most of the jobs: why are we not building this on more machines? The current job[1] is running on libvirt-centos-6 in addition to the ones you listed, so that should be included as well. However, I see no reason why we shouldn't be running this on libvirt-debian and libvirt-freebsd as well. I guess we want to be as close as possible to the manually-created setup at first, and build on that over time...
+Â Â Â Â title: Libvirt Python +Â Â Â Â jobs: +Â Â Â Â Â Â - python-distutils-build-job: +Â Â Â Â Â Â Â Â Â Â parent_jobs: +Â Â Â Â Â Â Â Â Â Â Â Â - 'libvirt-python-build' +Â Â Â Â Â Â Â Â Â Â Â Â - 'libosinfo-build' +Â Â Â Â Â Â - python-distutils-check-job: +Â Â Â Â Â Â Â Â Â Â parent_jobs: 'virt-manager-build' +Â Â Â Â Â Â - python-distutils-rpm-job: +Â Â Â Â Â Â Â Â Â Â parent_jobs: 'virt-manager-check'
[1] https://ci.centos.org/view/libvirt-project/job/virt-manager-build/ --Â Andrea Bolognani / Red Hat / Virtualization
On Fri, Aug 05, 2016 at 10:11:12AM +0200, Andrea Bolognani wrote:
On Thu, 2016-08-04 at 15:52 +0100, Daniel P. Berrange wrote:
Add a project defining the virt-manager package build jobs  Signed-off-by: Daniel P. Berrange <berrange@redhat.com> ---   projects/virt-manager.yaml | 19 +++++++++++++++++++   1 file changed, 19 insertions(+)   create mode 100644 projects/virt-manager.yaml  diff --git a/projects/virt-manager.yaml b/projects/virt-manager.yaml new file mode 100644 index 0000000..101a76c --- /dev/null +++ b/projects/virt-manager.yaml @@ -0,0 +1,19 @@ + +- project: +    name: virt-manager +    machines: +      - libvirt-centos-7 +      - libvirt-fedora-21 +      - libvirt-fedora-22 +      - libvirt-fedora-23 +      - libvirt-fedora-rawhide
I'm using virt-manager as an example here, but the question actually applies to most of the jobs: why are we not building this on more machines? The current job[1] is running on libvirt-centos-6 in addition to the ones you listed, so that should be included as well.
The current job is buggy - it depends on libosinfo job and that's not actually running on centos-6, hence I've disabled it here .
However, I see no reason why we shouldn't be running this on libvirt-debian and libvirt-freebsd as well. I guess we want to be as close as possible to the manually-created setup at first, and build on that over time...
In general you are right - I would like to expand this to cover more of the build hosts. Mostly it is a case of getting the right dependancies added to the build slaves in question. One of the reasons for moving the configs in to these text files is to make it easy for us to see what the build matrix is across the different jobs/machines.
+Â Â Â Â title: Libvirt Python +Â Â Â Â jobs: +Â Â Â Â Â Â - python-distutils-build-job: +Â Â Â Â Â Â Â Â Â Â parent_jobs: +Â Â Â Â Â Â Â Â Â Â Â Â - 'libvirt-python-build' +Â Â Â Â Â Â Â Â Â Â Â Â - 'libosinfo-build' +Â Â Â Â Â Â - python-distutils-check-job: +Â Â Â Â Â Â Â Â Â Â parent_jobs: 'virt-manager-build' +Â Â Â Â Â Â - python-distutils-rpm-job: +Â Â Â Â Â Â Â Â Â Â parent_jobs: 'virt-manager-check'
[1] https://ci.centos.org/view/libvirt-project/job/virt-manager-build/ --Â Andrea Bolognani / Red Hat / Virtualization
Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Add a project defining the libosinfo package build jobs Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- projects/libosinfo.yaml | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 projects/libosinfo.yaml diff --git a/projects/libosinfo.yaml b/projects/libosinfo.yaml new file mode 100644 index 0000000..a736559 --- /dev/null +++ b/projects/libosinfo.yaml @@ -0,0 +1,20 @@ + +- project: + name: libosinfo + machines: + - libvirt-centos-7 + - libvirt-fedora-21 + - libvirt-fedora-22 + - libvirt-fedora-23 + - libvirt-fedora-rawhide + title: osinfo database tools + projkey: 'libosinfo' + jobs: + - autotools-build-job: + parent_jobs: 'osinfo-db-build' + - autotools-syntax-check-job: + parent_jobs: 'libosinfo-build' + - autotools-check-job: + parent_jobs: 'libosinfo-syntax-check' + - autotools-rpm-job: + parent_jobs: 'libosinfo-rpm' -- 2.7.4
On Thu, 2016-08-04 at 15:52 +0100, Daniel P. Berrange wrote:
Add a project defining the libosinfo package build jobs  Signed-off-by: Daniel P. Berrange <berrange@redhat.com> ---   projects/libosinfo.yaml | 20 ++++++++++++++++++++   1 file changed, 20 insertions(+)   create mode 100644 projects/libosinfo.yaml  diff --git a/projects/libosinfo.yaml b/projects/libosinfo.yaml new file mode 100644 index 0000000..a736559 --- /dev/null +++ b/projects/libosinfo.yaml @@ -0,0 +1,20 @@ + +- project: +    name: libosinfo +    machines: +      - libvirt-centos-7 +      - libvirt-fedora-21 +      - libvirt-fedora-22 +      - libvirt-fedora-23 +      - libvirt-fedora-rawhide +    title: osinfo database tools
s/osinfo database tools/libosinfo/
+Â Â Â Â projkey: 'libosinfo' +Â Â Â Â jobs: +Â Â Â Â Â Â - autotools-build-job: +Â Â Â Â Â Â Â Â Â Â parent_jobs: 'osinfo-db-build' +Â Â Â Â Â Â - autotools-syntax-check-job: +Â Â Â Â Â Â Â Â Â Â parent_jobs: 'libosinfo-build' +Â Â Â Â Â Â - autotools-check-job: +Â Â Â Â Â Â Â Â Â Â parent_jobs: 'libosinfo-syntax-check' +Â Â Â Â Â Â - autotools-rpm-job: +Â Â Â Â Â Â Â Â Â Â parent_jobs: 'libosinfo-rpm'
--Â Andrea Bolognani / Red Hat / Virtualization
--- README | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 README diff --git a/README b/README new file mode 100644 index 0000000..9871cfc --- /dev/null +++ b/README @@ -0,0 +1,34 @@ + Libvirt Jenkins CI + ================== + +This package contains the libvirt Jenkins CI configuration tasks. + +This uses the jenkins job builder tool which can be installed + + $ pip install --user jenkins-job-builder + +The jobs/ directory contains general templates for defining +jobs for the different build systems (autotools, python distutils, +perl ExtUtils::MakeMaker, etc) + +The projects/ directory contains the per-project config which +activates the desired jobs and configures them if needed. + +It is possible to see the raw jenkins configuration using + + $ jenkins-jobs test -r . libvirt-glib-build + +Before updating the jobs on the server a file is needed to provide +the login details + + $ cat jenkins_jobs.ini + [jenkins] + user=XXX + password=XXX + url=https://ci.centos.org + + +To update the jenkins server with all jobs + + $ jenkins-jobs --conf jenkins_jobs.ini update -r . + -- 2.7.4
On Thu, Aug 04, 2016 at 03:52:09PM +0100, Daniel P. Berrange wrote:
We are using the CentOS Jenkins server for running CI tasks. Currently those tasks are maintained by people manually updating the Jenkins web UI. This is a horrible interface that requires 100's of mouse clicks to achieve even the simplest things. It is also incredibly hard to compare the config of different jobs to make sure they are working in a consistent manner.
Fortunately there are tools which can help - OpenStack created the jenkins-job-builder tool which uses the Jenkins REST API to create/update jobs from a simple YAML file definition.
This series thus creates a set of YAML files which will (almost) replicate our current manually create config.
I've used jenkins-job-builder in offline test mode to generate Jenkins XML files and then compared them to what we currently have and they are mostly the same. So there should not be too many suprises lurking, but I do still expect some accidental breakage in places. As such I have not actually uploaded the new auto-generated job configs to ci.centos.org at this time.
The intention is that these configs will all live in the libvirt GIT server in a new 'libvirt-jenkins-ci' repository
Hi Dan, wow nice job. I didn't know that there was this tool to maintain jobs for Jenkins. The web interface is horrible. I'm not sure why we need to build all the tools, we don't do it right now and even though we are using those tools, they have nothing in common with libvirt projects and friends. If we need to install those tools on all nodes, we should probably create another configuration/database of packages that are required to run all the jobs from all projects. Pavel
On Fri, Aug 05, 2016 at 10:29:17AM +0200, Pavel Hrdina wrote:
On Thu, Aug 04, 2016 at 03:52:09PM +0100, Daniel P. Berrange wrote:
We are using the CentOS Jenkins server for running CI tasks. Currently those tasks are maintained by people manually updating the Jenkins web UI. This is a horrible interface that requires 100's of mouse clicks to achieve even the simplest things. It is also incredibly hard to compare the config of different jobs to make sure they are working in a consistent manner.
Fortunately there are tools which can help - OpenStack created the jenkins-job-builder tool which uses the Jenkins REST API to create/update jobs from a simple YAML file definition.
This series thus creates a set of YAML files which will (almost) replicate our current manually create config.
I've used jenkins-job-builder in offline test mode to generate Jenkins XML files and then compared them to what we currently have and they are mostly the same. So there should not be too many suprises lurking, but I do still expect some accidental breakage in places. As such I have not actually uploaded the new auto-generated job configs to ci.centos.org at this time.
The intention is that these configs will all live in the libvirt GIT server in a new 'libvirt-jenkins-ci' repository
Hi Dan, wow nice job. I didn't know that there was this tool to maintain jobs for Jenkins. The web interface is horrible.
I'm not sure why we need to build all the tools, we don't do it right now and even though we are using those tools, they have nothing in common with libvirt projects and friends.
What do you mean by "build all the tools" ? Everything I have provided jobs for here, we *already* have running jobs for under libvirt CI.
If we need to install those tools on all nodes, we should probably create another configuration/database of packages that are required to run all the jobs from all projects.
We shouldn't install any pre-built packages for anything that we are capable of building from git, as git master branches cannot be assumed to work with older binary packaged versions, especially when getting to centos which is comparatively old. I already fixed this on the CI build slaves by removing a bunch of packages as we had some jobs building against things from git while other jobs we trying to build against deps from git but then accidentally picking up parts of the binary package install, so we have a horrible half&half build. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Fri, Aug 05, 2016 at 09:36:12AM +0100, Daniel P. Berrange wrote:
On Fri, Aug 05, 2016 at 10:29:17AM +0200, Pavel Hrdina wrote:
On Thu, Aug 04, 2016 at 03:52:09PM +0100, Daniel P. Berrange wrote:
We are using the CentOS Jenkins server for running CI tasks. Currently those tasks are maintained by people manually updating the Jenkins web UI. This is a horrible interface that requires 100's of mouse clicks to achieve even the simplest things. It is also incredibly hard to compare the config of different jobs to make sure they are working in a consistent manner.
Fortunately there are tools which can help - OpenStack created the jenkins-job-builder tool which uses the Jenkins REST API to create/update jobs from a simple YAML file definition.
This series thus creates a set of YAML files which will (almost) replicate our current manually create config.
I've used jenkins-job-builder in offline test mode to generate Jenkins XML files and then compared them to what we currently have and they are mostly the same. So there should not be too many suprises lurking, but I do still expect some accidental breakage in places. As such I have not actually uploaded the new auto-generated job configs to ci.centos.org at this time.
The intention is that these configs will all live in the libvirt GIT server in a new 'libvirt-jenkins-ci' repository
Hi Dan, wow nice job. I didn't know that there was this tool to maintain jobs for Jenkins. The web interface is horrible.
I'm not sure why we need to build all the tools, we don't do it right now and even though we are using those tools, they have nothing in common with libvirt projects and friends.
What do you mean by "build all the tools" ? Everything I have provided jobs for here, we *already* have running jobs for under libvirt CI.
I meant autotools, distuitls, and both Perl jobs.
If we need to install those tools on all nodes, we should probably create another configuration/database of packages that are required to run all the jobs from all projects.
We shouldn't install any pre-built packages for anything that we are capable of building from git, as git master branches cannot be assumed to work with older binary packaged versions, especially when getting to centos which is comparatively old. I already fixed this on the CI build slaves by removing a bunch of packages as we had some jobs building against things from git while other jobs we trying to build against deps from git but then accidentally picking up parts of the binary package install, so we have a horrible half&half build.
Well, when I was creating the Jenkins jobs, my idea was to use Fedora-rawhide for upstream builds where upstream libvirt-python is built against upstream libvirt and so on. For all other nodes the idea was to use system packages and build all projects against system packages. At least for libvirt I got the idea that it should be buildable also on older systems like Centos6 and that was my main motivation to apply this also on other project where it makes sense. Pavel
On Fri, Aug 05, 2016 at 10:55:55AM +0200, Pavel Hrdina wrote:
On Fri, Aug 05, 2016 at 09:36:12AM +0100, Daniel P. Berrange wrote:
On Fri, Aug 05, 2016 at 10:29:17AM +0200, Pavel Hrdina wrote:
On Thu, Aug 04, 2016 at 03:52:09PM +0100, Daniel P. Berrange wrote:
We are using the CentOS Jenkins server for running CI tasks. Currently those tasks are maintained by people manually updating the Jenkins web UI. This is a horrible interface that requires 100's of mouse clicks to achieve even the simplest things. It is also incredibly hard to compare the config of different jobs to make sure they are working in a consistent manner.
Fortunately there are tools which can help - OpenStack created the jenkins-job-builder tool which uses the Jenkins REST API to create/update jobs from a simple YAML file definition.
This series thus creates a set of YAML files which will (almost) replicate our current manually create config.
I've used jenkins-job-builder in offline test mode to generate Jenkins XML files and then compared them to what we currently have and they are mostly the same. So there should not be too many suprises lurking, but I do still expect some accidental breakage in places. As such I have not actually uploaded the new auto-generated job configs to ci.centos.org at this time.
The intention is that these configs will all live in the libvirt GIT server in a new 'libvirt-jenkins-ci' repository
Hi Dan, wow nice job. I didn't know that there was this tool to maintain jobs for Jenkins. The web interface is horrible.
I'm not sure why we need to build all the tools, we don't do it right now and even though we are using those tools, they have nothing in common with libvirt projects and friends.
What do you mean by "build all the tools" ? Everything I have provided jobs for here, we *already* have running jobs for under libvirt CI.
I meant autotools, distuitls, and both Perl jobs.
I'm still not sure what you mean. Those are all things we're using from existing jobs, so I've not added anything new that we don't already have.
If we need to install those tools on all nodes, we should probably create another configuration/database of packages that are required to run all the jobs from all projects.
We shouldn't install any pre-built packages for anything that we are capable of building from git, as git master branches cannot be assumed to work with older binary packaged versions, especially when getting to centos which is comparatively old. I already fixed this on the CI build slaves by removing a bunch of packages as we had some jobs building against things from git while other jobs we trying to build against deps from git but then accidentally picking up parts of the binary package install, so we have a horrible half&half build.
Well, when I was creating the Jenkins jobs, my idea was to use Fedora-rawhide for upstream builds where upstream libvirt-python is built against upstream libvirt and so on. For all other nodes the idea was to use system packages and build all projects against system packages.
At least for libvirt I got the idea that it should be buildable also on older systems like Centos6 and that was my main motivation to apply this also on other project where it makes sense.
That doesn't really work in general for tracking git master. For example this is why virt-manager builds stopped working for weeks on all the non rawhide platforms. I think the python binding is pretty much the only thing that is explicitly written to always be able to build against older libvirt. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Fri, Aug 05, 2016 at 10:41:25AM +0100, Daniel P. Berrange wrote:
On Fri, Aug 05, 2016 at 10:55:55AM +0200, Pavel Hrdina wrote:
On Fri, Aug 05, 2016 at 09:36:12AM +0100, Daniel P. Berrange wrote:
On Fri, Aug 05, 2016 at 10:29:17AM +0200, Pavel Hrdina wrote:
On Thu, Aug 04, 2016 at 03:52:09PM +0100, Daniel P. Berrange wrote:
We are using the CentOS Jenkins server for running CI tasks. Currently those tasks are maintained by people manually updating the Jenkins web UI. This is a horrible interface that requires 100's of mouse clicks to achieve even the simplest things. It is also incredibly hard to compare the config of different jobs to make sure they are working in a consistent manner.
Fortunately there are tools which can help - OpenStack created the jenkins-job-builder tool which uses the Jenkins REST API to create/update jobs from a simple YAML file definition.
This series thus creates a set of YAML files which will (almost) replicate our current manually create config.
I've used jenkins-job-builder in offline test mode to generate Jenkins XML files and then compared them to what we currently have and they are mostly the same. So there should not be too many suprises lurking, but I do still expect some accidental breakage in places. As such I have not actually uploaded the new auto-generated job configs to ci.centos.org at this time.
The intention is that these configs will all live in the libvirt GIT server in a new 'libvirt-jenkins-ci' repository
Hi Dan, wow nice job. I didn't know that there was this tool to maintain jobs for Jenkins. The web interface is horrible.
I'm not sure why we need to build all the tools, we don't do it right now and even though we are using those tools, they have nothing in common with libvirt projects and friends.
What do you mean by "build all the tools" ? Everything I have provided jobs for here, we *already* have running jobs for under libvirt CI.
I meant autotools, distuitls, and both Perl jobs.
I'm still not sure what you mean. Those are all things we're using from existing jobs, so I've not added anything new that we don't already have.
Having lunch apparently helped me understand the files under the jobs directory. Let's consider that this conversation didn't happen :).
If we need to install those tools on all nodes, we should probably create another configuration/database of packages that are required to run all the jobs from all projects.
We shouldn't install any pre-built packages for anything that we are capable of building from git, as git master branches cannot be assumed to work with older binary packaged versions, especially when getting to centos which is comparatively old. I already fixed this on the CI build slaves by removing a bunch of packages as we had some jobs building against things from git while other jobs we trying to build against deps from git but then accidentally picking up parts of the binary package install, so we have a horrible half&half build.
Well, when I was creating the Jenkins jobs, my idea was to use Fedora-rawhide for upstream builds where upstream libvirt-python is built against upstream libvirt and so on. For all other nodes the idea was to use system packages and build all projects against system packages.
At least for libvirt I got the idea that it should be buildable also on older systems like Centos6 and that was my main motivation to apply this also on other project where it makes sense.
That doesn't really work in general for tracking git master. For example this is why virt-manager builds stopped working for weeks on all the non rawhide platforms. I think the python binding is pretty much the only thing that is explicitly written to always be able to build against older libvirt.
Yes, it doesn't work in general, but in case of libvirt-python it works and libvirt-python is written that way and it would be nice to test it IMHO. In case of virt-manager it's because of wrong design of unit tests (they should not depend on environment or on installed packages). If the project depends on newer versions then the project should enforce this dependency like libvirt-perl does, otherwise it should be safe to build it against older versions. How about we make two categories of projects, ones that depends on latest version and the others that don't require latest versions? Pavel
On Fri, Aug 05, 2016 at 12:18:34PM +0200, Pavel Hrdina wrote:
On Fri, Aug 05, 2016 at 10:41:25AM +0100, Daniel P. Berrange wrote:
On Fri, Aug 05, 2016 at 10:55:55AM +0200, Pavel Hrdina wrote:
On Fri, Aug 05, 2016 at 09:36:12AM +0100, Daniel P. Berrange wrote:
On Fri, Aug 05, 2016 at 10:29:17AM +0200, Pavel Hrdina wrote:
On Thu, Aug 04, 2016 at 03:52:09PM +0100, Daniel P. Berrange wrote:
We are using the CentOS Jenkins server for running CI tasks. Currently those tasks are maintained by people manually updating the Jenkins web UI. This is a horrible interface that requires 100's of mouse clicks to achieve even the simplest things. It is also incredibly hard to compare the config of different jobs to make sure they are working in a consistent manner.
Fortunately there are tools which can help - OpenStack created the jenkins-job-builder tool which uses the Jenkins REST API to create/update jobs from a simple YAML file definition.
This series thus creates a set of YAML files which will (almost) replicate our current manually create config.
I've used jenkins-job-builder in offline test mode to generate Jenkins XML files and then compared them to what we currently have and they are mostly the same. So there should not be too many suprises lurking, but I do still expect some accidental breakage in places. As such I have not actually uploaded the new auto-generated job configs to ci.centos.org at this time.
The intention is that these configs will all live in the libvirt GIT server in a new 'libvirt-jenkins-ci' repository
Hi Dan, wow nice job. I didn't know that there was this tool to maintain jobs for Jenkins. The web interface is horrible.
I'm not sure why we need to build all the tools, we don't do it right now and even though we are using those tools, they have nothing in common with libvirt projects and friends.
What do you mean by "build all the tools" ? Everything I have provided jobs for here, we *already* have running jobs for under libvirt CI.
I meant autotools, distuitls, and both Perl jobs.
I'm still not sure what you mean. Those are all things we're using from existing jobs, so I've not added anything new that we don't already have.
Having lunch apparently helped me understand the files under the jobs directory. Let's consider that this conversation didn't happen :).
If we need to install those tools on all nodes, we should probably create another configuration/database of packages that are required to run all the jobs from all projects.
We shouldn't install any pre-built packages for anything that we are capable of building from git, as git master branches cannot be assumed to work with older binary packaged versions, especially when getting to centos which is comparatively old. I already fixed this on the CI build slaves by removing a bunch of packages as we had some jobs building against things from git while other jobs we trying to build against deps from git but then accidentally picking up parts of the binary package install, so we have a horrible half&half build.
Well, when I was creating the Jenkins jobs, my idea was to use Fedora-rawhide for upstream builds where upstream libvirt-python is built against upstream libvirt and so on. For all other nodes the idea was to use system packages and build all projects against system packages.
At least for libvirt I got the idea that it should be buildable also on older systems like Centos6 and that was my main motivation to apply this also on other project where it makes sense.
That doesn't really work in general for tracking git master. For example this is why virt-manager builds stopped working for weeks on all the non rawhide platforms. I think the python binding is pretty much the only thing that is explicitly written to always be able to build against older libvirt.
Yes, it doesn't work in general, but in case of libvirt-python it works and libvirt-python is written that way and it would be nice to test it IMHO. In case of virt-manager it's because of wrong design of unit tests (they should not depend on environment or on installed packages).
If the project depends on newer versions then the project should enforce this dependency like libvirt-perl does, otherwise it should be safe to build it against older versions.
How about we make two categories of projects, ones that depends on latest version and the others that don't require latest versions?
Doing that against host RPMs, leads to a rather unreliable environment. One set of projects will require a bunch of RPMs installed on the host to build against, while the other set will not want those RPMs installed and have to be careful not to accidentally build against them. To do this properly, I think we would have create a libvirt-stable job that uses a separate workspace from the main libvirt job and builds from an arbitrarily older stable branch, and installs into a different VIRT_PREFIX directory. We'd then have to create a second libvirt-python job that builds against this libvirt-stable job. This way we ensure we never pollute the build hosts with RPMs that could affect builds of the stuff that is supposed to be building against git master. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Fri, Aug 05, 2016 at 11:35:32AM +0100, Daniel P. Berrange wrote:
On Fri, Aug 05, 2016 at 12:18:34PM +0200, Pavel Hrdina wrote:
On Fri, Aug 05, 2016 at 10:41:25AM +0100, Daniel P. Berrange wrote:
On Fri, Aug 05, 2016 at 10:55:55AM +0200, Pavel Hrdina wrote:
On Fri, Aug 05, 2016 at 09:36:12AM +0100, Daniel P. Berrange wrote:
On Fri, Aug 05, 2016 at 10:29:17AM +0200, Pavel Hrdina wrote:
On Thu, Aug 04, 2016 at 03:52:09PM +0100, Daniel P. Berrange wrote: > We are using the CentOS Jenkins server for running CI tasks. > Currently those tasks are maintained by people manually > updating the Jenkins web UI. This is a horrible interface > that requires 100's of mouse clicks to achieve even the > simplest things. It is also incredibly hard to compare > the config of different jobs to make sure they are working > in a consistent manner. > > Fortunately there are tools which can help - OpenStack > created the jenkins-job-builder tool which uses the Jenkins > REST API to create/update jobs from a simple YAML file > definition. > > This series thus creates a set of YAML files which will > (almost) replicate our current manually create config. > > I've used jenkins-job-builder in offline test mode to > generate Jenkins XML files and then compared them to what > we currently have and they are mostly the same. So there > should not be too many suprises lurking, but I do still > expect some accidental breakage in places. As such I have > not actually uploaded the new auto-generated job configs > to ci.centos.org at this time. > > The intention is that these configs will all live in the > libvirt GIT server in a new 'libvirt-jenkins-ci' repository
Hi Dan, wow nice job. I didn't know that there was this tool to maintain jobs for Jenkins. The web interface is horrible.
I'm not sure why we need to build all the tools, we don't do it right now and even though we are using those tools, they have nothing in common with libvirt projects and friends.
What do you mean by "build all the tools" ? Everything I have provided jobs for here, we *already* have running jobs for under libvirt CI.
I meant autotools, distuitls, and both Perl jobs.
I'm still not sure what you mean. Those are all things we're using from existing jobs, so I've not added anything new that we don't already have.
Having lunch apparently helped me understand the files under the jobs directory. Let's consider that this conversation didn't happen :).
If we need to install those tools on all nodes, we should probably create another configuration/database of packages that are required to run all the jobs from all projects.
We shouldn't install any pre-built packages for anything that we are capable of building from git, as git master branches cannot be assumed to work with older binary packaged versions, especially when getting to centos which is comparatively old. I already fixed this on the CI build slaves by removing a bunch of packages as we had some jobs building against things from git while other jobs we trying to build against deps from git but then accidentally picking up parts of the binary package install, so we have a horrible half&half build.
Well, when I was creating the Jenkins jobs, my idea was to use Fedora-rawhide for upstream builds where upstream libvirt-python is built against upstream libvirt and so on. For all other nodes the idea was to use system packages and build all projects against system packages.
At least for libvirt I got the idea that it should be buildable also on older systems like Centos6 and that was my main motivation to apply this also on other project where it makes sense.
That doesn't really work in general for tracking git master. For example this is why virt-manager builds stopped working for weeks on all the non rawhide platforms. I think the python binding is pretty much the only thing that is explicitly written to always be able to build against older libvirt.
Yes, it doesn't work in general, but in case of libvirt-python it works and libvirt-python is written that way and it would be nice to test it IMHO. In case of virt-manager it's because of wrong design of unit tests (they should not depend on environment or on installed packages).
If the project depends on newer versions then the project should enforce this dependency like libvirt-perl does, otherwise it should be safe to build it against older versions.
How about we make two categories of projects, ones that depends on latest version and the others that don't require latest versions?
Doing that against host RPMs, leads to a rather unreliable environment. One set of projects will require a bunch of RPMs installed on the host to build against, while the other set will not want those RPMs installed and have to be careful not to accidentally build against them.
In that case we should cleanup the systems because at least libvirt and libvirt-python is installed on probably on all of them.
To do this properly, I think we would have create a libvirt-stable job that uses a separate workspace from the main libvirt job and builds from an arbitrarily older stable branch, and installs into a different VIRT_PREFIX directory. We'd then have to create a second libvirt-python job that builds against this libvirt-stable job. This way we ensure we never pollute the build hosts with RPMs that could affect builds of the stuff that is supposed to be building against git master.
That would be more robust solution. I've noticed that you've already switched to build only against git versions, so this could be the next step using this new Jenkins tool. Pavel
On Thu, Aug 04, 2016 at 03:52:09PM +0100, Daniel P. Berrange wrote:
We are using the CentOS Jenkins server for running CI tasks. Currently those tasks are maintained by people manually updating the Jenkins web UI. This is a horrible interface that requires 100's of mouse clicks to achieve even the simplest things. It is also incredibly hard to compare the config of different jobs to make sure they are working in a consistent manner.
Fortunately there are tools which can help - OpenStack created the jenkins-job-builder tool which uses the Jenkins REST API to create/update jobs from a simple YAML file definition.
This series thus creates a set of YAML files which will (almost) replicate our current manually create config.
I've used jenkins-job-builder in offline test mode to generate Jenkins XML files and then compared them to what we currently have and they are mostly the same. So there should not be too many suprises lurking, but I do still expect some accidental breakage in places. As such I have not actually uploaded the new auto-generated job configs to ci.centos.org at this time.
The intention is that these configs will all live in the libvirt GIT server in a new 'libvirt-jenkins-ci' repository
BTW, following on from this, I would like to create kickstart + puppet files for managing the build slaves & re-create the the slaves. This will give us a known good config that we can replicate elsewhere as needed. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Fri, Aug 05, 2016 at 11:54:17AM +0100, Daniel P. Berrange wrote:
On Thu, Aug 04, 2016 at 03:52:09PM +0100, Daniel P. Berrange wrote:
We are using the CentOS Jenkins server for running CI tasks. Currently those tasks are maintained by people manually updating the Jenkins web UI. This is a horrible interface that requires 100's of mouse clicks to achieve even the simplest things. It is also incredibly hard to compare the config of different jobs to make sure they are working in a consistent manner.
Fortunately there are tools which can help - OpenStack created the jenkins-job-builder tool which uses the Jenkins REST API to create/update jobs from a simple YAML file definition.
This series thus creates a set of YAML files which will (almost) replicate our current manually create config.
I've used jenkins-job-builder in offline test mode to generate Jenkins XML files and then compared them to what we currently have and they are mostly the same. So there should not be too many suprises lurking, but I do still expect some accidental breakage in places. As such I have not actually uploaded the new auto-generated job configs to ci.centos.org at this time.
The intention is that these configs will all live in the libvirt GIT server in a new 'libvirt-jenkins-ci' repository
BTW, following on from this, I would like to create kickstart + puppet files for managing the build slaves & re-create the the slaves. This will give us a known good config that we can replicate elsewhere as needed.
That's definitely good idea. As you've probably noticed there is a lot of env variables configured for all slaves. Is it possible to use the jenkins-jobs tool to configure those env variables too? I don't think that's a good idea configure those env variables directly inside the slaves since they are used only by Jenkins. Pavel
On Fri, Aug 05, 2016 at 01:22:52PM +0200, Pavel Hrdina wrote:
On Fri, Aug 05, 2016 at 11:54:17AM +0100, Daniel P. Berrange wrote:
On Thu, Aug 04, 2016 at 03:52:09PM +0100, Daniel P. Berrange wrote:
We are using the CentOS Jenkins server for running CI tasks. Currently those tasks are maintained by people manually updating the Jenkins web UI. This is a horrible interface that requires 100's of mouse clicks to achieve even the simplest things. It is also incredibly hard to compare the config of different jobs to make sure they are working in a consistent manner.
Fortunately there are tools which can help - OpenStack created the jenkins-job-builder tool which uses the Jenkins REST API to create/update jobs from a simple YAML file definition.
This series thus creates a set of YAML files which will (almost) replicate our current manually create config.
I've used jenkins-job-builder in offline test mode to generate Jenkins XML files and then compared them to what we currently have and they are mostly the same. So there should not be too many suprises lurking, but I do still expect some accidental breakage in places. As such I have not actually uploaded the new auto-generated job configs to ci.centos.org at this time.
The intention is that these configs will all live in the libvirt GIT server in a new 'libvirt-jenkins-ci' repository
BTW, following on from this, I would like to create kickstart + puppet files for managing the build slaves & re-create the the slaves. This will give us a known good config that we can replicate elsewhere as needed.
That's definitely good idea. As you've probably noticed there is a lot of env variables configured for all slaves. Is it possible to use the jenkins-jobs tool to configure those env variables too? I don't think that's a good idea configure those env variables directly inside the slaves since they are used only by Jenkins.
Yeah, we can trivially inject the env variables into all the job shell scripts directly now Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Thu, Aug 04, 2016 at 03:52:09PM +0100, Daniel P. Berrange wrote: Nice work, this will make the maintenance of Jenkins jobs a lot easier. ACK with the issues fixed.
On Fri, Aug 05, 2016 at 03:45:38PM +0200, Pavel Hrdina wrote:
On Thu, Aug 04, 2016 at 03:52:09PM +0100, Daniel P. Berrange wrote:
Nice work, this will make the maintenance of Jenkins jobs a lot easier.
ACK with the issues fixed.
FYI, I don't intend to push & update the jobs until next week now, since I don't want to break everything on a friday ;-) Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Fri, Aug 05, 2016 at 03:11:03PM +0100, Daniel P. Berrange wrote:
On Fri, Aug 05, 2016 at 03:45:38PM +0200, Pavel Hrdina wrote:
On Thu, Aug 04, 2016 at 03:52:09PM +0100, Daniel P. Berrange wrote:
Nice work, this will make the maintenance of Jenkins jobs a lot easier.
ACK with the issues fixed.
FYI, I don't intend to push & update the jobs until next week now, since I don't want to break everything on a friday ;-)
Ok, this is all now pushed. As expected there was a bunch of breakage which I've worked though. Just silly little bugs. I've pushed this series and a bunch of fixups after it. This is all in the 'libvirt-jenkins-ci.git' repository on the normal libvirt git server now. There's two little bugs i'm still chasing in virt-viewer & libvirt-tck RPM build processes. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
participants (3)
-
Andrea Bolognani -
Daniel P. Berrange -
Pavel Hrdina