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