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