Normally, if a change is made to a job configuration, we want to
ignore the file matchers and run the job so that we can see the
update in practice. However, we don't want to do so if the
*only* change to the job configuration is the file matchers. The
result is no different than before, and running the job tells us
nothing about the value of the change.
This behavior was already the case, but due to a bug. This
change both fixes the bug and intentionally restores the
behavior.
The bug that is corrected is that when variants were applied, the
actual file matchers attached to the frozen job were updated, but
not their string/list representation (stored in the '_files' and
'_irrelevant_files' attributes). This change moves those
attributes to the list of context attributes (which are
automatically copied on inheritance) -- the same as the actual
matcher attributes.
We also do the same for the '_branches' attribute (the text
version of the branch matcher). These changes make the
serialized form of the frozen job (which is returned by the web
api) more accurate. And in the case of the files matchers,
causes Zuul to correctly detect that the job has changed when
they are updated.
To restore the current (accidental but desired) behavior, we now
pop the files and irrelevant-files keys from the serialized
representation of the job before comparison when deciding whether
to run the job during a config update. This means that it will
only run if something other than a files matcher is changed.
This change also removes the _implied_branch job attribute
because it is no longer used anywhere (implied branches now
arrive via projects and project templates).
Change-Id: Id1d595873fe87ca980b2f33832f55542f9e5d496
9eef4e532a