Re: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job

[Daniel P . Berrangé]

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 :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job

[Andrea Bolognani]

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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job

[Daniel P . Berrangé]

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 :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job

[Andrea Bolognani]

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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job

[Daniel P . Berrangé]

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 :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job

[Andrea Bolognani]

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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job

[Daniel P . Berrangé]

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 :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job

[Andrea Bolognani]

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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job

[Daniel P . Berrangé]

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 :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job

[Andrea Bolognani]

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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job

[Daniel P . Berrangé]

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 :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job

[Andrea Bolognani]

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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job

[Daniel P . Berrangé]

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 
> ---
>  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 :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [jenkins-ci PATCH v2 3/6] projects: Add libvirt-master-website job

[Andrea Bolognani]

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 
---
 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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list