10:59 a.m.
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
10:59 a.m.
New subject: [libvirt] [jenkins-ci PATCH v2 1/6] jobs: Introduce autotools-website-job
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(a)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
4:52 a.m.
New subject: [libvirt] [jenkins-ci PATCH v2 1/6] jobs: Introduce autotools-website-job
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(a)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 :|
5:11 a.m.
New subject: [libvirt] [jenkins-ci PATCH v2 1/6] jobs: Introduce autotools-website-job
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
10:59 a.m.
New subject: [libvirt] [jenkins-ci PATCH v2 2/6] guests: Introduce libvirt+website project
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(a)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
4:53 a.m.
New subject: [libvirt] [jenkins-ci PATCH v2 2/6] guests: Introduce libvirt+website project
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(a)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(a)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 :|
10:59 a.m.
New subject: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job
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(a)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
4:54 a.m.
New subject: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job
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(a)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 :|
5:13 a.m.
New subject: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job
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
5:19 a.m.
New subject: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job
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 :|
5:41 a.m.
New subject: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job
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
7:08 a.m.
New subject: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job
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 :|
7:52 a.m.
New subject: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job
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
8:11 a.m.
New subject: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job
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 :|
8:28 a.m.
New subject: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job
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
8:33 a.m.
New subject: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job
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 :|
8:57 a.m.
New subject: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job
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
9:02 a.m.
New subject: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job
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 :|
9:21 a.m.
New subject: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job
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
9:23 a.m.
New subject: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job
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 :|
10:59 a.m.
New subject: [libvirt] [jenkins-ci PATCH v2 4/6] projects: Stop building on CentOS 6
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(a)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
4:55 a.m.
New subject: [libvirt] [jenkins-ci PATCH v2 4/6] projects: Stop building on CentOS 6
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(a)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(a)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 :|
10:59 a.m.
New subject: [libvirt] [jenkins-ci PATCH v2 5/6] guests: Drop projects from CentOS 6
Since the build jobs no longer target the platform, we can
avoid installing all the extra packages.
Signed-off-by: Andrea Bolognani <abologna(a)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
4:55 a.m.
New subject: [libvirt] [jenkins-ci PATCH v2 5/6] guests: Drop projects from CentOS 6
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(a)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(a)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 :|
10:59 a.m.
New subject: [libvirt] [jenkins-ci PATCH v2 6/6] jobs: Introduce {all_machines} and {rpm_machines}
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(a)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
5 a.m.
New subject: [libvirt] [jenkins-ci PATCH v2 6/6] jobs: Introduce {all_machines} and {rpm_machines}
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(a)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(a)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 :|
5:29 a.m.
New subject: [libvirt] [jenkins-ci PATCH v2 6/6] jobs: Introduce {all_machines} and {rpm_machines}
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
2411
days inactive
2416
days old
26 comments
2 participants
participants (2)
-
Andrea Bolognani -
Daniel P. Berrangé