We already have the infrastructure in place for adding warnings to the
reporting. Plumb that through to zuul_return so jobs can do that on
purpose as well. An example could be a post playbook that analyzes
performance statistics and emits a warning about inefficient usage of
the build node resources.
Change-Id: I4c3b85dc8f4c69c55cbc6168b8a66afce8b50a97
2019-05-15 10:14:22,482 ERROR zuul.Scheduler: Exception in run handler:
Traceback (most recent call last):
File "/opt/zuul/lib/python3.7/site-packages/zuul/scheduler.py", line 1062, in run
while (pipeline.manager.processQueue() and
File "/opt/zuul/lib/python3.7/site-packages/zuul/manager/__init__.py", line 788, in processQueue
item, nnfi)
File "/opt/zuul/lib/python3.7/site-packages/zuul/manager/__init__.py", line 744, in _processOneItem
if ready and self.executeJobs(item):
File "/opt/zuul/lib/python3.7/site-packages/zuul/manager/__init__.py", line 417, in executeJobs
item.pipeline.tenant.semaphore_handler)
File "/opt/zuul/lib/python3.7/site-packages/zuul/model.py", line 2450, in findJobsToRun
job.updateParentData(parent_build)
File "/opt/zuul/lib/python3.7/site-packages/zuul/model.py", line 1433, in updateParentData
artifacts = get_artifacts_from_result_data(other_vars)
File "/opt/zuul/lib/python3.7/site-packages/zuul/lib/artifacts.py", line 70, in get_artifacts_from_result_data
logger.debug("Result data did not pass artifact schema "
AttributeError: 'NoneType' object has no attribute 'debug'
Change-Id: I66d8541a242081be2d1a3d14c279108d34dc04fe
The schema validator for zuul.artifacts returned via zuul_return
did not allow for extra return data (outside of the zuul hierarchy).
Correct the validator to allow that, and update the test to exercise
it.
Change-Id: Ia8d7ed212b03d978bec1a7de1a2647b0c87b7cf9
This is a partial revert of f12453f6cb.
The use case that change was designed to address is poorly served by
that change. The intent was to make it easier to return multiple
artifacts in multiple playbooks independently by relying on the dictionary
merge behavior of zuul_return. However, in the entirely likely case
of artifacts with generated names, it becomes difficult because Ansible
does not run jinja on dictionary keys.
Therefore, revert to the previous list behavior. A subsequent change
will add a feature to zuul_return to address the underlying issue of
returning multiple artifacts from different playbooks.
Change-Id: I0581aa68fcef320ab27c11ddd6338a15eef38ceb
A recent attempt to use the artifact return feature of zuul_return
exposed some rough edges. These two changes should make it much
easier to use.
First, return artifacts as a dictionary instead of a list. This
requires that they have unique names (which is no bad thing -- what
would two artifacts named "docs" mean anyway?). But mainly it allows
the dict merging behavior of zuul_return to be used, so that one
playbook may use zuul_return with some artifacts, and another playbook
may do the same, without either needing to load in the values of
the other first (assuming, of course, that they use different artifact
names).
Second, add a metadata field. In the database and API, this is JSON
serialized, but in zuul_return and zuul.artifacts, it is exploded into
separate fields. This lets jobs do things like associate versions or
tags with artifacts without having to abuse the url field.
Change-Id: I228687c1bd1c74ebc33b088ffd43f30c7309990d
Adds support for expressing artifact dependencies between jobs
which may run in different projects.
Change-Id: If8cce8750d296d607841800e4bbf688a24c40e08
Tobias Henkel