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