tree 78a24a992f3416f4b034f1859e45ac734ba37548
parent f10f985b2f0c913fcc4a2501f3962caa61abaacf
author James E. Blair <jeblair@redhat.com> 1486512086 -0800
committer James E. Blair <jeblair@redhat.com> 1486749421 -0800

Inherit playbooks and modify job variance

An earlier change dealt with inheritance for pre and post playbooks;
they are nested so that parent job pre and post playbooks run first
and last respectively.

As for the actual playbook, since it's implied by the job name, it's
not clear whether it should be overidden or not.  We could drop that
and say that if you specify a 'run' attribute, it means you want to
set the playbook for a job, but if you omit it, you want to use the
parent's playbook.

However, we could keep the implied playbook behavior by making the
'run' attribute a list and adding a playbook context to the list each
time a job is inherited.  Then the launcher can walk the list in order
and the first playbook it finds, it runs.

This is what is implemented here.

However, we need to restrict playbooks or other execution-related
job attributes from being overidden by out-of-repo variants (such
as the implicit variant which is created by every entry in a
project-pipeline).  To do this, we make more of a distinction
between inheritance and variance, implementing each with its own
method on Job.  This way we can better control when certain
attributes are allowed to be set.  The 'final' job attribute is
added to indicate that a job should not accept any further
modifications to execution-related attributes.

The attribute storage in Job is altered so that each Job object
explicitly stores whether an attribute was set on it.  This makes
it easier to start with a job and apply only the specified
attributes of each variant in turn.  Default values are still
handled.

Essentially, each "job" appearance in the configuration will
create a new Job entry with exactly those attributes (with the
exception that a job where "parent" is set will first copy
attributes which are explicitly set on its parent).

When a job is frozen after an item is enqueued, the first
matching job is copied, and each subsequent matching job is
applied as a varient.  When that is completed, if the job has
un-inheritable auth information, it is set as final, and then the
project-pipeline variant is applied.

New tests are added to exercise the new methods on Job.

Change-Id: Iaf6d661a7bd0085e55bc301f83fe158fd0a70166