Now that the Zuul web server and database are both required, provide
a consistent user experience by always reporting the build page.
This means that success-url and failure-url are no longer useful,
so remove them.
Update the quick-start to reflect that the build page is always
reported.
Change-Id: I4ff108df3917c9b6f44e2f5b0ccc4a7adbda1677
So that a job may provide sensitive data to a child job without
those data ending up in the inventory file (and therefore in the
log archive) add a secret_data attribute to zuul_return.
Change-Id: I7cb8bed585eb6e94009647f490b9341927266e8f
Story: 2008389
The fix in https://review.opendev.org/#/c/698712/ introduced a
regression in that it doesn't allow skipping child jobs from a paused
job anymore.
Change-Id: I762597a24468f0745cea478485b2fc5d7f9ff6b7
When a job returns child jobs via zuul_return, the child jobs were not
skipped when the parent job failed in a later run or post playbook.
This can lead to hanging buildsets.
Change-Id: Ie61924f892bbd59899e77de1abd6a0f7610d7cbc
Consider the following Job-Graph:
/- (Job B) -\
| |
(Job A) -|- (Job C) -|- (Job E)
| |
\- (Job D) -/
Scenario A (is the implementation already working):
- Job A runs successfully
- Jobs B and C do not run because they are filtered by the "files"
attribute.
- Job D runs successfully
- Job E runs because it has a soft dependency on B, C, and D.
Scenario B (before this fix):
- Job A runs successfully and returns zuul.child_jobs = [Job D, Job E]
- Jobs B and C do not run because of job A (the "root job")
returns zuul.child_jobs not containing them
- Job D runs successfully
- Job E does not run even though it has a soft dependency on B, C and D
Scenario B (implementation fixed by this patch):
- Job A runs successfully and returns zuul.child_jobs = [Job D, Job E]
- Jobs B and C do not run because of job A (the "root job")
returns zuul.child_jobs not containing them
- Job D runs successfully
- Job E runs because it has a soft dependency on B, C, and D.
Change-Id: I1fe06d7a889dbccf86116a310701b2755e5fb385
Zuul has the possibility to skip child jobs using zuul_return. However
zuul still requests and locks nodes for these skipped jobs and never
returns them. If many jobs are skipped this can lead to a completely
wedged system. The only way to recover from this is to restart the
zuul-scheduler. This can be fixed by filtering out skipped jobs in
findJobsToRequest.
Change-Id: I69f7dd1fe142c5b4d8530407c3bca37fdd976597
Co-Authored-By: Tobias Henkel <tobias.henkel@bmw.de>
This fixes an issue when using zuul_return several times.
zuul_return module takes a dictionary as a parameter with one root key: 'zuul'
Using dict.update with two identical keys will cause dict key overriding
When using zuul_return in child and parent playbooks, the parent zuul_return
value overwrites the child zuul_return value
Change-Id: I6308020d2af0670eb5c598a3daf0ef51066651f6
Expose the ability for a user to skip child jobs using zuul_return and
zuul.child_jobs.
Change-Id: I21ea9b2d3b1711f0d55bbe3d626ac7dde5db2919
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Since jobs which use secrets in the trusted execution context are
always allowed, the name of this attribute was confusing. By renaming
it to 'post-review' (and the corresponding job attribute to
'post-review') we indicate what the actual concern is.
Change-Id: I59607621d5b99508b94074133bfc67e64e708a7d
After upgrading Gerrit to 2.13 our gate stopped working. The reason
for this is that after a successful gate run zuul does something like
'gerrit review --label verified=2 --submit'. The verified label in
Gerrit by default is configured as 'Verified'. The newer version of
gerrit behaves different now. It accepts the +2 vote on verified but
doesn't submit the patch anymore if the casing is not correct. This
forces us to specify the label in the same casing as gerrit
expects. In that case the tolower() in canMerge prevents the patch
from entering the gate.
In order to avoid confusion and be consistent, avoid any case
conversions and use the labels exactly as defined in Gerrit.
Note that this patch requires changes to the pipelines such that the
labels are spelled exactly as defined in Gerrit.
Change-Id: I9713a075e07b268e4f2620c0862c128158283c7c
And failure-url. This is an attempt to make it easy to use the
log_url return value, but still indicate that, say, the openstack
docs job should return a deep link to the doc index page.
Change-Id: I606fb7475a026f9a6d99c91b2b8e2223d7983daf
This loads a json file (work/results.json) that the job can write
to. It will be loaded by the executor after the job completes and
returned to the scheduler.
We can use the data in this file as the reported log URL for the
build. Later we can use it to supply file/line comments in
reviews.
Change-Id: Ib4eb743405f337c5bd541dd147e687fd44699713