[libvirt] [jenkins-ci PATCH v2 0/6] Mostly drop CentOS 6
Changes from [v1]: * instead of dropping CentOS 6 altogether, simply stop building pretty much all projects on it; * introduce a new job type specifically for whatever little stuff we need to ensure still works on CentOS 6; * the end result is still a nice cleanup thanks to not repeating the list of machines all over the place; moreover, the message about our support of the OS is very clear because it disappears from all but one page on the CI web interface. [v1] https://www.redhat.com/archives/libvir-list/2018-April/msg00453.html Andrea Bolognani (6): jobs: Introduce autotools-website-job guests: Introduce libvirt+website project projects: Add libvirt-master-website job projects: Stop building on CentOS 6 guests: Drop projects from CentOS 6 jobs: Introduce {all_machines} and {rpm_machines} guests/host_vars/libvirt-centos-6/main.yml | 5 +-- guests/vars/projects/libvirt+website.yml | 5 +++ jobs/autotools.yaml | 67 ++++++++++++++++++++++++++++++ jobs/defaults.yaml | 14 +++++++ projects/libosinfo.yaml | 16 +------ projects/libvirt-cim.yaml | 7 +--- projects/libvirt-glib.yaml | 16 +------ projects/libvirt-go-xml.yaml | 10 +---- projects/libvirt-go.yaml | 10 +---- projects/libvirt-perl.yaml | 17 +------- projects/libvirt-python.yaml | 18 +------- projects/libvirt.yaml | 34 +++++++-------- projects/osinfo-db-tools.yaml | 16 +------ projects/osinfo-db.yaml | 16 +------ projects/virt-viewer.yaml | 16 +------ 15 files changed, 119 insertions(+), 148 deletions(-) create mode 100644 guests/vars/projects/libvirt+website.yml -- 2.14.3
libvirt recently dropped support for running on CentOS 6, but the libvirt.org website still runs on that platform, so we need to be able to at least build documentation and create distribution tarballs a little while longer. autotools-website-job is the template for an ad-hoc job that does exactly that, thus guaranteeing that the bare minimum functionality we still need to work in CentOS 6 will, even as the library itself moves forward and possibly stops building on the OS altogether. Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- jobs/autotools.yaml | 67 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 67 insertions(+) diff --git a/jobs/autotools.yaml b/jobs/autotools.yaml index 0c164d3..9b26bc3 100644 --- a/jobs/autotools.yaml +++ b/jobs/autotools.yaml @@ -257,3 +257,70 @@ recipients: '{obj:spam}' notify-every-unstable-build: true send-to-individuals: false + +- job-template: + id: autotools-website-job + name: '{name}-{branch}-website' + project-type: matrix + description: '{title} Website' + autogen_args: '' + workspace: '{name}-{branch}-website' + child-workspace: '.' + block-downstream: true + block-upstream: true + wrappers: + - timeout: + abort: true + type: absolute + timeout: 90 + write-description: 'Aborted build after 90 minutes' + properties: + - build-discarder: + days-to-keep: 30 + num-to-keep: 1000 + scm: + - git: + url: git://n64.pufty.ci.centos.org/{name}.git + branches: + - origin/{branch} + clean: + after: true + skip-tag: true + wipe-workspace: false + triggers: + - reverse: + jobs: '{obj:parent_jobs}' + - pollscm: + cron: "H/20 * * * *" + axes: + - axis: + name: systems + type: slave + values: '{obj:machines}' + builders: + - shell: | + {global_env} + {local_env} + + # This job type is specifically tailored for the libvirt project + # and won't work anywhere else. Checking for libvirt.spec.in is + # a quick way to make sure the template is not being misused + test -e libvirt.spec.in + + mkdir build + cd build + + # Disable libvirtd and macvtap support to cut down the number + # of dependencies we need to install on the build worker + ../autogen.sh --without-libvirtd --without-macvtap + + # Build the website itself + $MAKE -j{smp} -C docs/ + + # Make sure we can build nightly source snapshots + $MAKE -j{smp} dist + publishers: + - email: + recipients: '{obj:spam}' + notify-every-unstable-build: true + send-to-individuals: false -- 2.14.3
On Thu, Apr 12, 2018 at 05:59:26PM +0200, Andrea Bolognani wrote:
libvirt recently dropped support for running on CentOS 6, but the libvirt.org website still runs on that platform, so we need to be able to at least build documentation and create distribution tarballs a little while longer.
autotools-website-job is the template for an ad-hoc job that does exactly that, thus guaranteeing that the bare minimum functionality we still need to work in CentOS 6 will, even as the library itself moves forward and possibly stops building on the OS altogether.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- jobs/autotools.yaml | 67 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 67 insertions(+)
diff --git a/jobs/autotools.yaml b/jobs/autotools.yaml index 0c164d3..9b26bc3 100644 --- a/jobs/autotools.yaml +++ b/jobs/autotools.yaml @@ -257,3 +257,70 @@ recipients: '{obj:spam}' notify-every-unstable-build: true send-to-individuals: false + +- job-template: + id: autotools-website-job + name: '{name}-{branch}-website' + project-type: matrix + description: '{title} Website' + autogen_args: '' + workspace: '{name}-{branch}-website' + child-workspace: '.' + block-downstream: true + block-upstream: true + wrappers: + - timeout: + abort: true + type: absolute + timeout: 90 + write-description: 'Aborted build after 90 minutes' + properties: + - build-discarder: + days-to-keep: 30 + num-to-keep: 1000 + scm: + - git: + url: git://n64.pufty.ci.centos.org/{name}.git + branches: + - origin/{branch} + clean: + after: true + skip-tag: true + wipe-workspace: false + triggers: + - reverse: + jobs: '{obj:parent_jobs}' + - pollscm: + cron: "H/20 * * * *" + axes: + - axis: + name: systems + type: slave + values: '{obj:machines}' + builders: + - shell: | + {global_env} + {local_env} + + # This job type is specifically tailored for the libvirt project + # and won't work anywhere else. Checking for libvirt.spec.in is + # a quick way to make sure the template is not being misused + test -e libvirt.spec.in + + mkdir build + cd build + + # Disable libvirtd and macvtap support to cut down the number + # of dependencies we need to install on the build worker + ../autogen.sh --without-libvirtd --without-macvtap + + # Build the website itself + $MAKE -j{smp} -C docs/ + + # Make sure we can build nightly source snapshots + $MAKE -j{smp} dist + publishers: + - email: + recipients: '{obj:spam}' + notify-every-unstable-build: true + send-to-individuals: false
IMHO adding this big single-use only job template is not desirable or needed. The point of templates is to provide reuse across many projects. Just define the libvirt-website job using the generic-build-job template instead. 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 :|
On Tue, 2018-04-17 at 10:52 +0100, Daniel P. Berrangé wrote:
On Thu, Apr 12, 2018 at 05:59:26PM +0200, Andrea Bolognani wrote:
diff --git a/jobs/autotools.yaml b/jobs/autotools.yaml index 0c164d3..9b26bc3 100644 --- a/jobs/autotools.yaml +++ b/jobs/autotools.yaml @@ -257,3 +257,70 @@ recipients: '{obj:spam}' notify-every-unstable-build: true send-to-individuals: false + +- job-template: + id: autotools-website-job + name: '{name}-{branch}-website' + project-type: matrix + description: '{title} Website' + autogen_args: '' + workspace: '{name}-{branch}-website' [...]
IMHO adding this big single-use only job template is not desirable or needed. The point of templates is to provide reuse across many projects. Just define the libvirt-website job using the generic-build-job template instead.
Good point. The only problem I can see with that approach is that such a job would share the same workspace as the regular libvirt builds, which is something that we don't want in general; however, given that the website job is only going to be running on CentOS 6 and vice versa, we can safely go ahead with it. -- Andrea Bolognani / Red Hat / Virtualization
Building the website and creating distribution tarballs requires very few dependencies compared to performing a full build of libvirt, so we introduce a separate, leaner project for the purpose. Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- guests/vars/projects/libvirt+website.yml | 5 +++++ 1 file changed, 5 insertions(+) create mode 100644 guests/vars/projects/libvirt+website.yml diff --git a/guests/vars/projects/libvirt+website.yml b/guests/vars/projects/libvirt+website.yml new file mode 100644 index 0000000..128ed8c --- /dev/null +++ b/guests/vars/projects/libvirt+website.yml @@ -0,0 +1,5 @@ +--- +packages: + - libxml2 + - rpcgen + - xsltproc -- 2.14.3
On Thu, Apr 12, 2018 at 05:59:27PM +0200, Andrea Bolognani wrote:
Building the website and creating distribution tarballs requires very few dependencies compared to performing a full build of libvirt, so we introduce a separate, leaner project for the purpose.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- guests/vars/projects/libvirt+website.yml | 5 +++++ 1 file changed, 5 insertions(+) create mode 100644 guests/vars/projects/libvirt+website.yml
diff --git a/guests/vars/projects/libvirt+website.yml b/guests/vars/projects/libvirt+website.yml new file mode 100644 index 0000000..128ed8c --- /dev/null +++ b/guests/vars/projects/libvirt+website.yml @@ -0,0 +1,5 @@ +--- +packages: + - libxml2 + - rpcgen + - xsltproc
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> 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 :|
This will ensure libvirt maintains the minimum amount of compatibility with CentOS 6 that running its website on that platform requires. Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- guests/host_vars/libvirt-centos-6/main.yml | 1 + projects/libvirt.yaml | 4 ++++ 2 files changed, 5 insertions(+) diff --git a/guests/host_vars/libvirt-centos-6/main.yml b/guests/host_vars/libvirt-centos-6/main.yml index 422d033..8261c3d 100644 --- a/guests/host_vars/libvirt-centos-6/main.yml +++ b/guests/host_vars/libvirt-centos-6/main.yml @@ -4,6 +4,7 @@ PYTHONPATH: $VIRT_PREFIX/lib64/python2.6/site-packages projects: - libvirt + - libvirt+website - libvirt-cim - libvirt-perl - libvirt-python diff --git a/projects/libvirt.yaml b/projects/libvirt.yaml index 13f39f9..427cf6a 100644 --- a/projects/libvirt.yaml +++ b/projects/libvirt.yaml @@ -43,3 +43,7 @@ parent_jobs: machines: - libvirt-fedora-rawhide + - autotools-website-job: + parent_jobs: + machines: + - libvirt-centos-6 -- 2.14.3
On Thu, Apr 12, 2018 at 05:59:28PM +0200, Andrea Bolognani wrote:
This will ensure libvirt maintains the minimum amount of compatibility with CentOS 6 that running its website on that platform requires.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- guests/host_vars/libvirt-centos-6/main.yml | 1 + projects/libvirt.yaml | 4 ++++ 2 files changed, 5 insertions(+)
diff --git a/guests/host_vars/libvirt-centos-6/main.yml b/guests/host_vars/libvirt-centos-6/main.yml index 422d033..8261c3d 100644 --- a/guests/host_vars/libvirt-centos-6/main.yml +++ b/guests/host_vars/libvirt-centos-6/main.yml @@ -4,6 +4,7 @@ PYTHONPATH: $VIRT_PREFIX/lib64/python2.6/site-packages
projects: - libvirt + - libvirt+website - libvirt-cim - libvirt-perl - libvirt-python diff --git a/projects/libvirt.yaml b/projects/libvirt.yaml index 13f39f9..427cf6a 100644 --- a/projects/libvirt.yaml +++ b/projects/libvirt.yaml @@ -43,3 +43,7 @@ parent_jobs: machines: - libvirt-fedora-rawhide + - autotools-website-job:
Use 'generic-build-job' here
+ parent_jobs: + machines: + - libvirt-centos-6
And just add command: | mkdir build && cd build ../autogen.sh --without-libvirtd --without-macvtap $MAKE -j{smp} -C docs $MAKE -j{smp} dist 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 :|
On Tue, 2018-04-17 at 10:54 +0100, Daniel P. Berrangé wrote:
On Thu, Apr 12, 2018 at 05:59:28PM +0200, Andrea Bolognani wrote:
diff --git a/projects/libvirt.yaml b/projects/libvirt.yaml index 13f39f9..427cf6a 100644 --- a/projects/libvirt.yaml +++ b/projects/libvirt.yaml @@ -43,3 +43,7 @@ parent_jobs: machines: - libvirt-fedora-rawhide + - autotools-website-job:
Use 'generic-build-job' here
+ parent_jobs: + machines: + - libvirt-centos-6
And just add
command: | mkdir build && cd build ../autogen.sh --without-libvirtd --without-macvtap $MAKE -j{smp} -C docs $MAKE -j{smp} dist
Okay. Do you want me to send v2, or can I just squash this in and push? -- Andrea Bolognani / Red Hat / Virtualization
On Tue, Apr 17, 2018 at 12:13:01PM +0200, Andrea Bolognani wrote:
On Tue, 2018-04-17 at 10:54 +0100, Daniel P. Berrangé wrote:
On Thu, Apr 12, 2018 at 05:59:28PM +0200, Andrea Bolognani wrote:
diff --git a/projects/libvirt.yaml b/projects/libvirt.yaml index 13f39f9..427cf6a 100644 --- a/projects/libvirt.yaml +++ b/projects/libvirt.yaml @@ -43,3 +43,7 @@ parent_jobs: machines: - libvirt-fedora-rawhide + - autotools-website-job:
Use 'generic-build-job' here
+ parent_jobs: + machines: + - libvirt-centos-6
And just add
command: | mkdir build && cd build ../autogen.sh --without-libvirtd --without-macvtap $MAKE -j{smp} -C docs $MAKE -j{smp} dist
Okay.
Do you want me to send v2, or can I just squash this in and push?
Fine to squash it unless you notice something complicated needs furtehr changing. 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 :|
On Tue, 2018-04-17 at 11:19 +0100, Daniel P. Berrangé wrote:
On Tue, Apr 17, 2018 at 12:13:01PM +0200, Andrea Bolognani wrote:
Do you want me to send v2, or can I just squash this in and push?
Fine to squash it unless you notice something complicated needs furtehr changing.
Hm, Jenkins Job Builder is actually not happy with that: ERROR:jenkins_jobs.parser:Duplicate definitions for job 'libvirt-master-build' specified which makes sense because generic-build-jobs has name: '{name}-{branch}-build' I could trick it into using a different name with - generic-build-job: name: libvirt-website ... but then it would try to fetch new revisions from git://n64.pufty.ci.centos.org/libvirt-website.git which of course doesn't exist... Given the situation, my original approach might be the best solution to the problem after all. What's your take? -- Andrea Bolognani / Red Hat / Virtualization
On Tue, Apr 17, 2018 at 12:41:09PM +0200, Andrea Bolognani wrote:
On Tue, 2018-04-17 at 11:19 +0100, Daniel P. Berrangé wrote:
On Tue, Apr 17, 2018 at 12:13:01PM +0200, Andrea Bolognani wrote:
Do you want me to send v2, or can I just squash this in and push?
Fine to squash it unless you notice something complicated needs furtehr changing.
Hm, Jenkins Job Builder is actually not happy with that:
ERROR:jenkins_jobs.parser:Duplicate definitions for job 'libvirt-master-build' specified
which makes sense because generic-build-jobs has
name: '{name}-{branch}-build'
I could trick it into using a different name with
- generic-build-job: name: libvirt-website ...
but then it would try to fetch new revisions from
git://n64.pufty.ci.centos.org/libvirt-website.git
which of course doesn't exist...
Given the situation, my original approach might be the best solution to the problem after all. What's your take?
Hmm, this is a problem with us repurposing 'name' as a parameter for the template, when it is also a declared field. eg the core issue is this: name: '{name}-{branch}-build' We should address this by changing the parameter name to be 'projname', so it doesn't clash with the official 'name' field used as the job name. 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 :|
On Tue, 2018-04-17 at 13:08 +0100, Daniel P. Berrangé wrote:
Hmm, this is a problem with us repurposing 'name' as a parameter for the template, when it is also a declared field.
eg the core issue is this:
name: '{name}-{branch}-build'
We should address this by changing the parameter name to be 'projname', so it doesn't clash with the official 'name' field used as the job name.
Are you sure? It seems to me like the problem stems from the fact that we have both - job-template: id: autotools-build-job name: '{name}-{branch}-build' and - job-template: id: generic-build-job name: '{name}-{branch}-build' Even if we had a separate 'projname' parameter, the names of the generated jobs would end up being the same. I guess we could come up with a - job-template: id: generic-command-job name: '{name}-{branch}-{unique}' but that template would need to include the scm: configuration and everything else... Basically, it would end up looking pretty much exactly like like generic-build-job or the autotools-website-job I proposed. Having a more generic version of that would be a net win if we had a bunch of these oddball jobs, but with a single one (which we will hopefully be able to drop at some point in the not-too-distant future!) on the table we might as well not bother. -- Andrea Bolognani / Red Hat / Virtualization
On Tue, Apr 17, 2018 at 02:52:08PM +0200, Andrea Bolognani wrote:
On Tue, 2018-04-17 at 13:08 +0100, Daniel P. Berrangé wrote:
Hmm, this is a problem with us repurposing 'name' as a parameter for the template, when it is also a declared field.
eg the core issue is this:
name: '{name}-{branch}-build'
We should address this by changing the parameter name to be 'projname', so it doesn't clash with the official 'name' field used as the job name.
Are you sure? It seems to me like the problem stems from the fact that we have both
- job-template: id: autotools-build-job name: '{name}-{branch}-build'
and
- job-template: id: generic-build-job name: '{name}-{branch}-build'
Even if we had a separate 'projname' parameter, the names of the generated jobs would end up being the same.
I meant that if we had 'projname' parameter, then we have the ability to override the job name using: 'name: libvirt-master-website' without affecting all the expansion of all the other bits of the template, as they now get driven by {projname} instead. 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 :|
On Tue, 2018-04-17 at 14:11 +0100, Daniel P. Berrangé wrote:
On Tue, Apr 17, 2018 at 02:52:08PM +0200, Andrea Bolognani wrote:
Are you sure? It seems to me like the problem stems from the fact that we have both
- job-template: id: autotools-build-job name: '{name}-{branch}-build'
and
- job-template: id: generic-build-job name: '{name}-{branch}-build'
Even if we had a separate 'projname' parameter, the names of the generated jobs would end up being the same.
I meant that if we had 'projname' parameter, then we have the ability to override the job name using:
'name: libvirt-master-website'
without affecting all the expansion of all the other bits of the template, as they now get driven by {projname} instead.
Okay, I see what you mean now. I'm not sure I would necessarily consider it a better approach, though: it requires making *all* project definitions uglier ('name' just looks more natural than 'projname' IMHO), with a bunch of churn to get there, and after all that trouble the libvirt-master-website job still needs to break the template abstraction in order to work at all. All to avoid bit duplicating one more time a bunch of YAML that's already copied and pasted pretty much verbatim several times over. tl;dr I still like my approach better, but if you're absolutely opposed to it I'll begrudgingly take a stab at implementing your proposal for the sake of sidelining CentOS 6 further :) -- Andrea Bolognani / Red Hat / Virtualization
On Tue, Apr 17, 2018 at 03:28:38PM +0200, Andrea Bolognani wrote:
On Tue, 2018-04-17 at 14:11 +0100, Daniel P. Berrangé wrote:
On Tue, Apr 17, 2018 at 02:52:08PM +0200, Andrea Bolognani wrote:
Are you sure? It seems to me like the problem stems from the fact that we have both
- job-template: id: autotools-build-job name: '{name}-{branch}-build'
and
- job-template: id: generic-build-job name: '{name}-{branch}-build'
Even if we had a separate 'projname' parameter, the names of the generated jobs would end up being the same.
I meant that if we had 'projname' parameter, then we have the ability to override the job name using:
'name: libvirt-master-website'
without affecting all the expansion of all the other bits of the template, as they now get driven by {projname} instead.
Okay, I see what you mean now.
I'm not sure I would necessarily consider it a better approach, though: it requires making *all* project definitions uglier ('name' just looks more natural than 'projname' IMHO), with a bunch of churn to get there, and after all that trouble the libvirt-master-website job still needs to break the template abstraction in order to work at all.
Personally I'd like to do the name -> jobname change regardless, but I don't think its actually needed after all. Instead just change the templates from doing name: '{name}-{branch}-build' to name: '{name}-{branch}-build{jobsuffix}' Then the website job can just set jobsuffix: website and everything else can leave it unset 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 :|
On Tue, 2018-04-17 at 14:33 +0100, Daniel P. Berrangé wrote:
Instead just change the templates from doing
name: '{name}-{branch}-build'
to
name: '{name}-{branch}-build{jobsuffix}'
Then the website job can just set
jobsuffix: website
and everything else can leave it unset
This one I like better :) We could go one further and use name: '{name}-{branch}-build{variant}' for the generic-build-job template and variant: +website for this specific job, then change the autotools-mingw-job template to use name: '{name}-{branch}-build+mingw' to align the job names with the project names at the Ansible level. We could then even think about dropping autotools-mingw-job altogether and instead use generic-build-job there as well, like - project: name: libvirt jobs: - generic-build-job: variant: +mingw command: '{mingw_build}' where 'mingw_build' would be defined globally. -- Andrea Bolognani / Red Hat / Virtualization
On Tue, Apr 17, 2018 at 03:57:04PM +0200, Andrea Bolognani wrote:
On Tue, 2018-04-17 at 14:33 +0100, Daniel P. Berrangé wrote:
Instead just change the templates from doing
name: '{name}-{branch}-build'
to
name: '{name}-{branch}-build{jobsuffix}'
Then the website job can just set
jobsuffix: website
and everything else can leave it unset
This one I like better :)
We could go one further and use
name: '{name}-{branch}-build{variant}'
for the generic-build-job template and
variant: +website
for this specific job, then change the autotools-mingw-job template to use
name: '{name}-{branch}-build+mingw'
to align the job names with the project names at the Ansible level.
Yes, that would be reasonable, though I prefer '-' rather than '+', since we're already using '-' to separate the first three terms that make up the job name - no reason why the variant should be treated differently in the naming scheme.
We could then even think about dropping autotools-mingw-job altogether and instead use generic-build-job there as well, like
- project: name: libvirt jobs: - generic-build-job: variant: +mingw command: '{mingw_build}'
where 'mingw_build' would be defined globally.
I don't think that's desirable as {mingw_build} ends up duplicating the shell commands defined by the autotools-build-job template. Instead we shoudl make use of existing parameterization of the existing autotools template - project: name: libvirt jobs: - autotools-build-job: variant: +mingw local_env: {mingw32_env} autogen_args: {mingw32_autogen} With mingw32_env: | export PKG_CONFIG_LIBDIR="/usr/i686-w64-mingw32/sys-root/mingw/lib/pkgconfig:/usr/i686-w64-mingw32/sys-root/mingw/share/pkgconfig" export PKG_CONFIG_PATH="$VIRT_PREFIX/i686-w64-mingw32/sys-root/mingw/lib/pkgconfig" \ export PREFIX=$VIRT_PREFIX/i686-w64-mingw32/sys-root/mingw mingw32_autogen: --host=i686-w64-mingw32 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 :|
On Tue, 2018-04-17 at 15:02 +0100, Daniel P. Berrangé wrote:
On Tue, Apr 17, 2018 at 03:57:04PM +0200, Andrea Bolognani wrote:
We could go one further and use
name: '{name}-{branch}-build{variant}'
for the generic-build-job template and
variant: +website
for this specific job, then change the autotools-mingw-job template to use
name: '{name}-{branch}-build+mingw'
to align the job names with the project names at the Ansible level.
Yes, that would be reasonable, though I prefer '-' rather than '+', since we're already using '-' to separate the first three terms that make up the job name - no reason why the variant should be treated differently in the naming scheme.
I went for '+' in the Ansible part because using '-' would introduce ambiguity: is 'libvirt-mingw' a variant of libvirt, or just a completely different project like 'libvirt-dbus'? In the case of Jenkins jobs, we have already lost that battle thanks to jobs like virt-manager-master-build, so I guess it's okay to keep using '-' :)
We could then even think about dropping autotools-mingw-job altogether and instead use generic-build-job there as well, like
- project: name: libvirt jobs: - generic-build-job: variant: +mingw command: '{mingw_build}'
where 'mingw_build' would be defined globally.
I don't think that's desirable as {mingw_build} ends up duplicating the shell commands defined by the autotools-build-job template.
Instead we shoudl make use of existing parameterization of the existing autotools template
- project: name: libvirt jobs: - autotools-build-job: variant: +mingw local_env: {mingw32_env} autogen_args: {mingw32_autogen}
With
mingw32_env: | export PKG_CONFIG_LIBDIR="/usr/i686-w64-mingw32/sys-root/mingw/lib/pkgconfig:/usr/i686-w64-mingw32/sys-root/mingw/share/pkgconfig" export PKG_CONFIG_PATH="$VIRT_PREFIX/i686-w64-mingw32/sys-root/mingw/lib/pkgconfig" \ export PREFIX=$VIRT_PREFIX/i686-w64-mingw32/sys-root/mingw
mingw32_autogen: --host=i686-w64-mingw32
Yeah, that looks good too. It'll lead to having separate -mingw32 and -mingw64 jobs, though: personally I don't have a problem with that, just making sure you don't either. -- Andrea Bolognani / Red Hat / Virtualization
On Tue, Apr 17, 2018 at 04:21:19PM +0200, Andrea Bolognani wrote:
On Tue, 2018-04-17 at 15:02 +0100, Daniel P. Berrangé wrote:
On Tue, Apr 17, 2018 at 03:57:04PM +0200, Andrea Bolognani wrote:
We could go one further and use
name: '{name}-{branch}-build{variant}'
for the generic-build-job template and
variant: +website
for this specific job, then change the autotools-mingw-job template to use
name: '{name}-{branch}-build+mingw'
to align the job names with the project names at the Ansible level.
Yes, that would be reasonable, though I prefer '-' rather than '+', since we're already using '-' to separate the first three terms that make up the job name - no reason why the variant should be treated differently in the naming scheme.
I went for '+' in the Ansible part because using '-' would introduce ambiguity: is 'libvirt-mingw' a variant of libvirt, or just a completely different project like 'libvirt-dbus'?
In the case of Jenkins jobs, we have already lost that battle thanks to jobs like virt-manager-master-build, so I guess it's okay to keep using '-' :)
We could then even think about dropping autotools-mingw-job altogether and instead use generic-build-job there as well, like
- project: name: libvirt jobs: - generic-build-job: variant: +mingw command: '{mingw_build}'
where 'mingw_build' would be defined globally.
I don't think that's desirable as {mingw_build} ends up duplicating the shell commands defined by the autotools-build-job template.
Instead we shoudl make use of existing parameterization of the existing autotools template
- project: name: libvirt jobs: - autotools-build-job: variant: +mingw local_env: {mingw32_env} autogen_args: {mingw32_autogen}
With
mingw32_env: | export PKG_CONFIG_LIBDIR="/usr/i686-w64-mingw32/sys-root/mingw/lib/pkgconfig:/usr/i686-w64-mingw32/sys-root/mingw/share/pkgconfig" export PKG_CONFIG_PATH="$VIRT_PREFIX/i686-w64-mingw32/sys-root/mingw/lib/pkgconfig" \ export PREFIX=$VIRT_PREFIX/i686-w64-mingw32/sys-root/mingw
mingw32_autogen: --host=i686-w64-mingw32
Yeah, that looks good too.
It'll lead to having separate -mingw32 and -mingw64 jobs, though: personally I don't have a problem with that, just making sure you don't either.
I think that is a benefit :-) There's no reason beyond historical accident to lump them together ! 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 :|
CentOS 6 is no longer a supported target platform for libvirt, which means all other projects can't target it either. Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- projects/libvirt-cim.yaml | 1 - projects/libvirt-perl.yaml | 1 - projects/libvirt-python.yaml | 2 -- projects/libvirt.yaml | 3 --- 4 files changed, 7 deletions(-) diff --git a/projects/libvirt-cim.yaml b/projects/libvirt-cim.yaml index c1a0914..160faaf 100644 --- a/projects/libvirt-cim.yaml +++ b/projects/libvirt-cim.yaml @@ -2,7 +2,6 @@ - project: name: libvirt-cim machines: - - libvirt-centos-6 - libvirt-centos-7 - libvirt-fedora-26 - libvirt-fedora-27 diff --git a/projects/libvirt-perl.yaml b/projects/libvirt-perl.yaml index 3912876..eb1ee77 100644 --- a/projects/libvirt-perl.yaml +++ b/projects/libvirt-perl.yaml @@ -2,7 +2,6 @@ - project: name: libvirt-perl machines: - - libvirt-centos-6 - libvirt-centos-7 - libvirt-debian-8 - libvirt-debian-9 diff --git a/projects/libvirt-python.yaml b/projects/libvirt-python.yaml index dd8ac13..26accf4 100644 --- a/projects/libvirt-python.yaml +++ b/projects/libvirt-python.yaml @@ -2,7 +2,6 @@ - project: name: libvirt-python machines: - - libvirt-centos-6 - libvirt-centos-7 - libvirt-debian-8 - libvirt-debian-9 @@ -20,7 +19,6 @@ - python-distutils-rpm-job: parent_jobs: 'libvirt-python-master-check' machines: - - libvirt-centos-6 - libvirt-centos-7 - libvirt-fedora-26 - libvirt-fedora-27 diff --git a/projects/libvirt.yaml b/projects/libvirt.yaml index 427cf6a..2715164 100644 --- a/projects/libvirt.yaml +++ b/projects/libvirt.yaml @@ -2,7 +2,6 @@ - project: name: libvirt machines: - - libvirt-centos-6 - libvirt-centos-7 - libvirt-debian-8 - libvirt-debian-9 @@ -15,7 +14,6 @@ - autotools-build-job: parent_jobs: machines: - - libvirt-centos-6 - libvirt-centos-7 - libvirt-debian-8 - libvirt-debian-9 @@ -34,7 +32,6 @@ - autotools-rpm-job: parent_jobs: 'libvirt-master-check' machines: - - libvirt-centos-6 - libvirt-centos-7 - libvirt-fedora-26 - libvirt-fedora-27 -- 2.14.3
On Thu, Apr 12, 2018 at 05:59:29PM +0200, Andrea Bolognani wrote:
CentOS 6 is no longer a supported target platform for libvirt, which means all other projects can't target it either.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- projects/libvirt-cim.yaml | 1 - projects/libvirt-perl.yaml | 1 - projects/libvirt-python.yaml | 2 -- projects/libvirt.yaml | 3 --- 4 files changed, 7 deletions(-)
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> 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 :|
Since the build jobs no longer target the platform, we can avoid installing all the extra packages. Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- guests/host_vars/libvirt-centos-6/main.yml | 4 ---- 1 file changed, 4 deletions(-) diff --git a/guests/host_vars/libvirt-centos-6/main.yml b/guests/host_vars/libvirt-centos-6/main.yml index 8261c3d..fe9a47b 100644 --- a/guests/host_vars/libvirt-centos-6/main.yml +++ b/guests/host_vars/libvirt-centos-6/main.yml @@ -3,8 +3,4 @@ PERL5LIB: $VIRT_PREFIX/lib64/perl5 PYTHONPATH: $VIRT_PREFIX/lib64/python2.6/site-packages projects: - - libvirt - libvirt+website - - libvirt-cim - - libvirt-perl - - libvirt-python -- 2.14.3
On Thu, Apr 12, 2018 at 05:59:30PM +0200, Andrea Bolognani wrote:
Since the build jobs no longer target the platform, we can avoid installing all the extra packages.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- guests/host_vars/libvirt-centos-6/main.yml | 4 ---- 1 file changed, 4 deletions(-)
diff --git a/guests/host_vars/libvirt-centos-6/main.yml b/guests/host_vars/libvirt-centos-6/main.yml index 8261c3d..fe9a47b 100644 --- a/guests/host_vars/libvirt-centos-6/main.yml +++ b/guests/host_vars/libvirt-centos-6/main.yml @@ -3,8 +3,4 @@ PERL5LIB: $VIRT_PREFIX/lib64/perl5 PYTHONPATH: $VIRT_PREFIX/lib64/python2.6/site-packages
projects: - - libvirt - libvirt+website - - libvirt-cim - - libvirt-perl - - libvirt-python
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> 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 :|
We're running most of the jobs on all machines, with the major notable exception being the various *-rpm jobs which of course only make sense for RPM-based distributions. Instead of listing machines over and over again, define two list globally and refer to them by name. Ad-hoc machine lists are still needed in a few places, but overall this cuts down on repetition significantly. Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- jobs/defaults.yaml | 14 ++++++++++++++ projects/libosinfo.yaml | 16 ++-------------- projects/libvirt-cim.yaml | 6 +----- projects/libvirt-glib.yaml | 16 ++-------------- projects/libvirt-go-xml.yaml | 10 +--------- projects/libvirt-go.yaml | 10 +--------- projects/libvirt-perl.yaml | 16 ++-------------- projects/libvirt-python.yaml | 16 ++-------------- projects/libvirt.yaml | 27 +++++++++++---------------- projects/osinfo-db-tools.yaml | 16 ++-------------- projects/osinfo-db.yaml | 16 ++-------------- projects/virt-viewer.yaml | 16 ++-------------- 12 files changed, 42 insertions(+), 137 deletions(-) diff --git a/jobs/defaults.yaml b/jobs/defaults.yaml index 23f8555..9fe69de 100644 --- a/jobs/defaults.yaml +++ b/jobs/defaults.yaml @@ -3,6 +3,20 @@ name: global branch: master node: libvirt + all_machines: + - libvirt-centos-7 + - libvirt-debian-8 + - libvirt-debian-9 + - libvirt-fedora-26 + - libvirt-fedora-27 + - libvirt-fedora-rawhide + - libvirt-freebsd-10 + - libvirt-freebsd-11 + rpm_machines: + - libvirt-centos-7 + - libvirt-fedora-26 + - libvirt-fedora-27 + - libvirt-fedora-rawhide global_env: | local_env: | smp: 3 diff --git a/projects/libosinfo.yaml b/projects/libosinfo.yaml index ac04027..0d25447 100644 --- a/projects/libosinfo.yaml +++ b/projects/libosinfo.yaml @@ -1,15 +1,7 @@ - project: name: libosinfo - machines: - - libvirt-centos-7 - - libvirt-debian-8 - - libvirt-debian-9 - - libvirt-fedora-26 - - libvirt-fedora-27 - - libvirt-fedora-rawhide - - libvirt-freebsd-10 - - libvirt-freebsd-11 + machines: '{all_machines}' title: libosinfo jobs: - autotools-build-job: @@ -20,8 +12,4 @@ parent_jobs: 'libosinfo-master-syntax-check' - autotools-rpm-job: parent_jobs: 'libosinfo-master-check' - machines: - - libvirt-centos-7 - - libvirt-fedora-26 - - libvirt-fedora-27 - - libvirt-fedora-rawhide + machines: '{rpm_machines}' diff --git a/projects/libvirt-cim.yaml b/projects/libvirt-cim.yaml index 160faaf..dff3976 100644 --- a/projects/libvirt-cim.yaml +++ b/projects/libvirt-cim.yaml @@ -1,11 +1,7 @@ - project: name: libvirt-cim - machines: - - libvirt-centos-7 - - libvirt-fedora-26 - - libvirt-fedora-27 - - libvirt-fedora-rawhide + machines: '{rpm_machines}' title: libvirt CIM jobs: - autotools-build-job: diff --git a/projects/libvirt-glib.yaml b/projects/libvirt-glib.yaml index 74f7642..741ac44 100644 --- a/projects/libvirt-glib.yaml +++ b/projects/libvirt-glib.yaml @@ -1,15 +1,7 @@ - project: name: libvirt-glib - machines: - - libvirt-centos-7 - - libvirt-debian-8 - - libvirt-debian-9 - - libvirt-fedora-26 - - libvirt-fedora-27 - - libvirt-fedora-rawhide - - libvirt-freebsd-10 - - libvirt-freebsd-11 + machines: '{all_machines}' title: Libvirt GLib jobs: - autotools-build-job: @@ -21,8 +13,4 @@ parent_jobs: 'libvirt-glib-master-syntax-check' - autotools-rpm-job: parent_jobs: 'libvirt-glib-master-check' - machines: - - libvirt-centos-7 - - libvirt-fedora-26 - - libvirt-fedora-27 - - libvirt-fedora-rawhide + machines: '{rpm_machines}' diff --git a/projects/libvirt-go-xml.yaml b/projects/libvirt-go-xml.yaml index 126058b..1f26751 100644 --- a/projects/libvirt-go-xml.yaml +++ b/projects/libvirt-go-xml.yaml @@ -1,15 +1,7 @@ - project: name: libvirt-go-xml - machines: - - libvirt-centos-7 - - libvirt-debian-8 - - libvirt-debian-9 - - libvirt-fedora-26 - - libvirt-fedora-27 - - libvirt-fedora-rawhide - - libvirt-freebsd-10 - - libvirt-freebsd-11 + machines: '{all_machines}' title: Libvirt Go XML local_env: | export TEST_ARGS="-tags xmlroundtrip" diff --git a/projects/libvirt-go.yaml b/projects/libvirt-go.yaml index 141c862..f40f523 100644 --- a/projects/libvirt-go.yaml +++ b/projects/libvirt-go.yaml @@ -1,15 +1,7 @@ - project: name: libvirt-go - machines: - - libvirt-centos-7 - - libvirt-debian-8 - - libvirt-debian-9 - - libvirt-fedora-26 - - libvirt-fedora-27 - - libvirt-fedora-rawhide - - libvirt-freebsd-10 - - libvirt-freebsd-11 + machines: '{all_machines}' title: Libvirt Go local_env: | export TEST_ARGS="-tags api" diff --git a/projects/libvirt-perl.yaml b/projects/libvirt-perl.yaml index eb1ee77..0a6f648 100644 --- a/projects/libvirt-perl.yaml +++ b/projects/libvirt-perl.yaml @@ -1,15 +1,7 @@ - project: name: libvirt-perl - machines: - - libvirt-centos-7 - - libvirt-debian-8 - - libvirt-debian-9 - - libvirt-fedora-26 - - libvirt-fedora-27 - - libvirt-fedora-rawhide - - libvirt-freebsd-10 - - libvirt-freebsd-11 + machines: '{all_machines}' title: Libvirt Perl jobs: - perl-makemaker-build-job: @@ -19,8 +11,4 @@ test_args: 'TEST_MAINTAINER=1' - perl-makemaker-rpm-job: parent_jobs: 'libvirt-perl-master-test' - machines: - - libvirt-centos-7 - - libvirt-fedora-26 - - libvirt-fedora-27 - - libvirt-fedora-rawhide + machines: '{rpm_machines}' diff --git a/projects/libvirt-python.yaml b/projects/libvirt-python.yaml index 26accf4..1e742da 100644 --- a/projects/libvirt-python.yaml +++ b/projects/libvirt-python.yaml @@ -1,15 +1,7 @@ - project: name: libvirt-python - machines: - - libvirt-centos-7 - - libvirt-debian-8 - - libvirt-debian-9 - - libvirt-fedora-26 - - libvirt-fedora-27 - - libvirt-fedora-rawhide - - libvirt-freebsd-10 - - libvirt-freebsd-11 + machines: '{all_machines}' title: Libvirt Python jobs: - python-distutils-build-job: @@ -18,8 +10,4 @@ parent_jobs: 'libvirt-python-master-build' - python-distutils-rpm-job: parent_jobs: 'libvirt-python-master-check' - machines: - - libvirt-centos-7 - - libvirt-fedora-26 - - libvirt-fedora-27 - - libvirt-fedora-rawhide + machines: '{rpm_machines}' diff --git a/projects/libvirt.yaml b/projects/libvirt.yaml index 2715164..ee5c259 100644 --- a/projects/libvirt.yaml +++ b/projects/libvirt.yaml @@ -1,18 +1,14 @@ - project: name: libvirt - machines: - - libvirt-centos-7 - - libvirt-debian-8 - - libvirt-debian-9 - - libvirt-fedora-26 - - libvirt-fedora-27 - - libvirt-fedora-rawhide + machines: '{all_machines}' title: Libvirt archive_format: xz jobs: - autotools-build-job: parent_jobs: + - autotools-syntax-check-job: + parent_jobs: 'libvirt-master-build' machines: - libvirt-centos-7 - libvirt-debian-8 @@ -20,22 +16,21 @@ - libvirt-fedora-26 - libvirt-fedora-27 - libvirt-fedora-rawhide - - libvirt-freebsd-10 - - libvirt-freebsd-11 - - autotools-syntax-check-job: - parent_jobs: 'libvirt-master-build' - autotools-check-job: parent_jobs: 'libvirt-master-syntax-check' - local_env: | - export VIR_TEST_EXPENSIVE=1 - export VIR_TEST_DEBUG=2 - - autotools-rpm-job: - parent_jobs: 'libvirt-master-check' machines: - libvirt-centos-7 + - libvirt-debian-8 + - libvirt-debian-9 - libvirt-fedora-26 - libvirt-fedora-27 - libvirt-fedora-rawhide + local_env: | + export VIR_TEST_EXPENSIVE=1 + export VIR_TEST_DEBUG=2 + - autotools-rpm-job: + parent_jobs: 'libvirt-master-check' + machines: '{rpm_machines}' - autotools-mingw-job: parent_jobs: machines: diff --git a/projects/osinfo-db-tools.yaml b/projects/osinfo-db-tools.yaml index e51a064..6b451ef 100644 --- a/projects/osinfo-db-tools.yaml +++ b/projects/osinfo-db-tools.yaml @@ -1,15 +1,7 @@ - project: name: osinfo-db-tools - machines: - - libvirt-centos-7 - - libvirt-debian-8 - - libvirt-debian-9 - - libvirt-fedora-26 - - libvirt-fedora-27 - - libvirt-fedora-rawhide - - libvirt-freebsd-10 - - libvirt-freebsd-11 + machines: '{all_machines}' title: osinfo database tools jobs: - autotools-build-job: @@ -20,8 +12,4 @@ parent_jobs: 'osinfo-db-tools-master-syntax-check' - autotools-rpm-job: parent_jobs: 'osinfo-db-tools-master-check' - machines: - - libvirt-centos-7 - - libvirt-fedora-26 - - libvirt-fedora-27 - - libvirt-fedora-rawhide + machines: '{rpm_machines}' diff --git a/projects/osinfo-db.yaml b/projects/osinfo-db.yaml index 7f83722..0d0a972 100644 --- a/projects/osinfo-db.yaml +++ b/projects/osinfo-db.yaml @@ -1,15 +1,7 @@ - project: name: osinfo-db - machines: - - libvirt-centos-7 - - libvirt-debian-8 - - libvirt-debian-9 - - libvirt-fedora-26 - - libvirt-fedora-27 - - libvirt-fedora-rawhide - - libvirt-freebsd-10 - - libvirt-freebsd-11 + machines: '{all_machines}' title: osinfo database jobs: - generic-build-job: @@ -23,11 +15,7 @@ $MAKE -j{smp} check - generic-rpm-job: parent_jobs: 'osinfo-db-master-check' - machines: - - libvirt-centos-7 - - libvirt-fedora-26 - - libvirt-fedora-27 - - libvirt-fedora-rawhide + machines: '{rpm_machines}' command: | rm -f *.tar.xz $MAKE osinfo-db.spec diff --git a/projects/virt-viewer.yaml b/projects/virt-viewer.yaml index 90cd787..647b963 100644 --- a/projects/virt-viewer.yaml +++ b/projects/virt-viewer.yaml @@ -1,15 +1,7 @@ - project: name: virt-viewer - machines: - - libvirt-centos-7 - - libvirt-debian-8 - - libvirt-debian-9 - - libvirt-fedora-26 - - libvirt-fedora-27 - - libvirt-fedora-rawhide - - libvirt-freebsd-10 - - libvirt-freebsd-11 + machines: '{all_machines}' title: Virt Viewer jobs: - autotools-build-job: @@ -20,8 +12,4 @@ parent_jobs: 'virt-viewer-master-syntax-check' - autotools-rpm-job: parent_jobs: 'virt-viewer-master-check' - machines: - - libvirt-centos-7 - - libvirt-fedora-26 - - libvirt-fedora-27 - - libvirt-fedora-rawhide + machines: '{rpm_machines}' -- 2.14.3
On Thu, Apr 12, 2018 at 05:59:31PM +0200, Andrea Bolognani wrote:
We're running most of the jobs on all machines, with the major notable exception being the various *-rpm jobs which of course only make sense for RPM-based distributions.
Instead of listing machines over and over again, define two list globally and refer to them by name. Ad-hoc machine lists are still needed in a few places, but overall this cuts down on repetition significantly.
Seems like the key reason for the divergance is skipping syntax-check and check jobs on *BSD. Sure would be nice to figure out how to get these working one day.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- jobs/defaults.yaml | 14 ++++++++++++++ projects/libosinfo.yaml | 16 ++-------------- projects/libvirt-cim.yaml | 6 +----- projects/libvirt-glib.yaml | 16 ++-------------- projects/libvirt-go-xml.yaml | 10 +--------- projects/libvirt-go.yaml | 10 +--------- projects/libvirt-perl.yaml | 16 ++-------------- projects/libvirt-python.yaml | 16 ++-------------- projects/libvirt.yaml | 27 +++++++++++---------------- projects/osinfo-db-tools.yaml | 16 ++-------------- projects/osinfo-db.yaml | 16 ++-------------- projects/virt-viewer.yaml | 16 ++-------------- 12 files changed, 42 insertions(+), 137 deletions(-)
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> 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 :|
On Tue, 2018-04-17 at 11:00 +0100, Daniel P. Berrangé wrote:
On Thu, Apr 12, 2018 at 05:59:31PM +0200, Andrea Bolognani wrote:
We're running most of the jobs on all machines, with the major notable exception being the various *-rpm jobs which of course only make sense for RPM-based distributions.
Instead of listing machines over and over again, define two list globally and refer to them by name. Ad-hoc machine lists are still needed in a few places, but overall this cuts down on repetition significantly.
Seems like the key reason for the divergance is skipping syntax-check and check jobs on *BSD. Sure would be nice to figure out how to get these working one day.
That's one of the reasons, but I wouldn't say it's the key one: libvirt-dbus, libvirt-sandbox, libvirt-tck and virt-manager also need special casing for various reasons related to eg. some of the libraries not being recent enough, or not shipped at all, in some distributions. -- Andrea Bolognani / Red Hat / Virtualization
participants (2)
-
Andrea Bolognani -
Daniel P. Berrangé