[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [jenkins-ci PATCH 0/2] fix libosinfo rpm build



On Thu, Nov 02, 2017 at 04:32:12PM +0100, Andrea Bolognani wrote:
> On Thu, 2017-11-02 at 13:45 +0100, Pavel Hrdina wrote:
> > Pavel Hrdina (2):
> >   jobs: rename check_env into job_env
> >   jobs: use job_env in all job templates
> > 
> >  jobs/autotools.yaml      | 5 ++++-
> >  jobs/defaults.yaml       | 2 +-
> >  jobs/perl-makemaker.yaml | 3 +++
> >  projects/libosinfo.yaml  | 2 +-
> >  projects/libvirt.yaml    | 2 +-
> >  5 files changed, 10 insertions(+), 4 deletions(-)
> 
> I'm not sure this approach is the best one.
> 
> I like the idea of having a place where we can stick common
> environment variables - for us that mostly means paths, and we
> should definitely move guest configuration out of its definition
> in Jenkins and into this repository, as we prototyped yesterday.

This is a fix of the commit that broke it, I'm not trying to move all
environment variables out of Jenkins.

> But here you're still keeping that info local. Moreover, you're
> moving the VIR_TEST_* variables from check_env to job_env, which
> means they end up being defined even during regular 'make'. I seem
> to recall Dan speaking up against that earlier.

This is not true, the VIR_TEST_* variables are defined only for
"autotools-check-job", see <projects/libvirt.yaml>.

> 
> I think we should have:
> 
>   global_env - as the name implies, global; for $VIRT_PREFIX and all
>                other paths that affect one or more build jobs, like
>                $OSINFO_SYSTEM_DIR and $MAKE

I'm not sure whether there is some different way how to do it but I
would rather use different approach than using these defines since
you can easily overwrite them and forget to include it.

>   build_env  - local; for variables that affect the build step of a
>                single job (can't think of any right now)
>   test_env   - local; for variables that affect the test suite of a
>                single job, like $VIR_TEST_DEBUG

I thought about splitting it into {build,test} but we don't need to have
it that way and it feels like an overkill.

> For projects that inherit from anything but generic-*-job,
> global_env will be included automatically; projects that don't use
> any of the known build system will have to take care of that
> themselves, but then again they already have to do that for make_env.

And this is exactly why I don't want to do it this way, the "global_env"
needs to be present always, like it is now with all the environment
variables configured in Jenkins.

> Moreover, we should be able to convert libvirt-cim to use
> autotools-*-job by tweaking its autogen.sh script, which would leave
> osinfo-db as the only user of generic-*-job.

+1

Pavel

Attachment: signature.asc
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]