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
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
