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
Freze Zuul job variables when starting a build so that jinja
templates can not be used to expose secrets. The values will be
frozen by running a playbook with set_fact, and that playbook
will run without access to secrets. After the playbook
completes, the frozen variables are read from and then removed
from the fact cache. They are then supplied as normal inventory
variables for any trusted playbooks or playbooks with secrets.
The regular un-frozen variables are used for all other untrusted
playbooks.
Extra-vars are now only used to establish precedence among all
Zuul job variables. They are no longer passed to Ansible with
the "-e" command line option, as that level of precedence could
also be used to obtain secrets.
Much of this work is accomplished by "squashing" all of the Zuul
job, host, group, and extra variables into a flat structure for
each host in the inventory. This means that much of the variable
precedence is now handled by Zuul, which then gives Ansible
variables as host vars. The actual inventory files will be much
more verbose now, since each host will have a copy of every "all"
value. But this allows the freezing process to be much simpler.
When writing the inventory for the setup playbook, we now use the
!unsafe YAML tag which is understood by Ansible to indicate that
it should not perform jinja templating on variables. This may
help to avoid any mischief with templated variables since they
have not yet been frozen.
Also, be more strict about what characters are allowed in ansible
variable names. We already checked job variables, but we didn't
verify that secret names/aliases met the ansible variable
requirements. A check is added for that (and a unit test that
relied on the erroneous behavior is updated).
Story: 2008664
Story: 2008682
Change-Id: I04d8b822fda6628e87a4a57dc368f20d84ae5ea9
In some cases test_playbook fails on contended nodes. The reason is
that the job timeout repeatedly times out already during the pre
playbook causing it to re-run instead of failing with result
TIMED_OUT. To make this more robust give it a higher timeout so it can
reach the run playbook.
Change-Id: I042c25217138c3d96683b1494fc3be9cf395f6a1
The test_playbook test in the Ansible tests (which tests a bunch of
interactions between Zuul and Ansible) has a test job called "timeout"
which verifies that everything works if a job timeout hits while
ansible is running. We currently allow the job to run for 5 seconds,
but that includes both pre-run and run playbooks. Sometimes the job
runs slowly and we hit the timeout during the pre-run playbook, which
means it gets retried, which the test does not expect. Double our
allowance and let the job run for 10 seconds before hitting the timeout
so that it's more likely it hits during the run playbook.
Change-Id: I396647117f7362c4b547ed374292c12bd5a73435
This code had a bug -- it didn't build the full path.
This code was not tested.
These two things are related.
Change-Id: I7881fb30017cedc12435e0fcbfda321bdf20d611
Unit test playbooks are generally written as
- hosts: all
tasks:
...
However, many of the unit tests don't specify any nodes for their
jobs. With no nodes specified, Ansible gets a empty host list and
thus the only host available is the special "implicit localhost".
Since "all" doesn't match the implicit localhost, under normal
circumstances Ansible does not match anything and doesn't run any of
the playbooks.
To get around this, the extant code in
RecordingAnsibleJob:getHostList() (tests/base.py) overrides the host
list and explicitly adds a host named "localhost". This is put into
the Ansible inventory and now the "all" matcher has something to match
against and the playbooks run. This work-around was initially added
with I5e23f330476f064acf3cb87f746c5d3193cce274.
The situation became a bit more confused with
Iacf670d992bb051560a0c46c313beaa6721489c4 where the "localhost" fake
node is only added if other nodes are *not* specified. Several tests
rely on this now as they specify various forms of nodes explicitly and
don't want this fake node added.
This change removes the automatic addition of "localhost" in
unit-tests all together. I believe this is the correct direction to
move in, because it's a fairly confusing anti-feature if, for example,
you write a unit test that *is* explicitly executor-only (i.e. a blank
node list). Such a test fails because the unit-test framework adds a
host for you; something that does not happen in production. It's also
a bit confusing if you're reading the config files and thinking
"hosts: all shouldn't match anything here" without digging into the
test framework.
There are two ways this could be fixed. The playbooks that are part
of jobs that have no nodes defined could be re-written to "hosts:
localhost" so that they match the "implicit localhost" and always run.
This does not really seem to be their intent, however. The other
option, which is taken here, is to always add nodes to the job. I
believe this is a better approach, as it more closely matches what you
would see in actual jobs.
Change-Id: I6b52b7e4bc591c09034461b534ca5225945f76cf
In some cases, the pre-run playbook for the timeout job, will actually
timeout. This is bad because it causes zuul to run the timeout job
again, resulting in 2 timeout build results.
Given that we wait up to 60 seconds in our playbook, increase this to 5
seconds to give a little more forgiveness.
Change-Id: I71e83c808822e88075791a2d11d498d01afc2abe
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Like pre-run and post-run, allow a user to run a list of playbooks for
a job. One example would be your job workflow would be to run multiple
playbooks over using a site.yaml file with include_playbook commands.
A second use case, more related to job design. With multiple playbooks
support for job.run, the first playbook would be use deploy your server
and the second playbook to validate the server was provisioned properly.
Today, this can be done using a single run and post-run playbooks,
however if post-run fails, zuul will return POST_FAILURE, not FAILURE.
Not a large issue, but could be confusing to users when POST_FAILURE is
returned.
While it is possible a user could create a single site.yaml playbook,
and use multiple include_playbook statements to get this functionality,
there are downsides to this approach (mostly with the leaking of
variables). Today, operators simply run ansible-playbook multiple times
with the specific playbooks they only want.
Story: 2002543
Task: 22101
Change-Id: I6268d9944e745cc07407ea7dd040fbfeb79dad4d
Related-To: https://review.openstack.org/519596
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Currently, variables using the extra-vars flags always win precedence
over any other variable in ansible. There is also a 2nd use case where
playbooks variables for serial, hosts, etc can only be set using
extra-vars CLI flag.
While this could be achieved by using secrets today, it doesn't feel
like the correct way to use them. Additionally, secrets are
dictionary values in ansible, making them hard to use the filters like
default().
Change-Id: I6d8018661f8d13b7324a012cdbf9614e983e5114
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
If we want to use configuration objects between layouts, we can't change
them once they are loaded. To validate that the code doesn't do that,
and prevent regressions, make them immutable after loading is complete.
A variable is added to the base job in the check-vars ansible test to make
sure that we exercise Job.applyVariant in the case where the base job
starts with a variable defined.
Change-Id: I42d01962c4b2dd3cdfce3641ea367b4f4f6892c9
This adds a post-timeout setting which applies as a timeout to each
post-run playbook. This is separate and independent of the normal job
timeout which now only applies to the pre-run and run playbooks in a
cumulative fashion.
The reason for this change is when a pre-run or run playbook hits the
timeout and the job fails you still want to do your best to copy all of
the log data that you can find so that you can debug the timeout.
Similarly to timeout, if post-timeout is not set then post-run playbooks
will have no timeout and can run indefinitely.
Change-Id: I830a6a14d2623f50fbc3f05396cc909d79de04bb
These playbook paths were missing ".yaml" extentions which fails when
implied matching goes away (Ie2519f2b4144761b8e4d17ec3299cf4238e16f08).
Change-Id: Iff04d894fffdcec0a0861d2460635b4c44a15ae4
We intended to have Nodesets be convenience methods for the 'nodes'
attribute of jobs, but be identical. When nodesets grew groups,
however, job.nodes did not. Because of the additional structure
that nodesets contain (to support groups, and likely vars in the
future), we can't simply extend the existing nodes parameter.
Add a new parameter, nodeset, which expects either a string or
an embedded nodeset definition. We're using the name 'nodeset'
here because 'nodes: nodes:' is difficult to understand.
Job.nodes will be removed soon.
(Re-proposed from I714887625c41bd1220ff05cd7356fbac589389c9)
Change-Id: I6c1c1e864704ac659efae9b28b140d9b37cef9d2
There are some cases, such as the artifact upload job, where the job can
take a dict parameter and where it could be advantageous to allow other
people to re-use the job but passing in their own local secret data by
supplying variables to a variant. However, currently secrets carry with
them a name, which is used as the variable name in ansible.
Make a secret in a job config be able to be given as a string or a
dict. In the dict case, the name of the secret and the name it should be
added to ansible as are required. This allows someone to have a named
secret but to pass it to a job under a different name.
Change-Id: I27a82c6ee1cf7399353509f98a0a52536ebbc19a
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
It would be useful to allow deployment specific configuration that can
be fed into the project-config deployments so that we can customize
things like host ip without having to change job definitions for each
site.
Also, add a method to display the build log from a failed assertion in
the Ansible test (this was used in the development of the tests for
this change).
Change-Id: I87e8bffc540bcafab543c46244f3d5327b56fcae
Co-Authored-By: James E. Blair <jeblair@redhat.com>
We're providing more than one uuid to the job, so to make it clear
that one is for the build, and one is for the buildset, use those
words.
Change-Id: If9ebdc783dcef4f8dea9fa491b40ae49416e5cf1
The failure-url is not used when formatting jobs with a result of e.g.
POST_FAILURE or TIME_OUT. Fix this by defaulting to the failure-url
for any non-success result.
This also enhances the test_playbook test with a broken post playbook
and tests for the correct urls.
Change-Id: I8485dee83e36275a1dd439f12cf8c0fdf90999ca
This change drops the playbooks/ location for pre and post playbooks
in any case and for main playbooks if the run argument is given.
That way the playbooks can be placed in arbitrary locations giving the
projects more flexibility how to structure their repo.
Change-Id: I84d42f9b293df716a7a0759c7127b6f705c075c2
We are keeping the 'label' terminology in nodepool, and since that
is actually what zuul asks for, use that terminology here to avoid
confusion.
Change-Id: I5f5f1cd041b6dbd80a75af66fe02520f3eb32151
We want to properly flex our bubblewrap implementation, this job does
so.
Change-Id: I6647d71434a8d8f6621d3fd34883683ef149775a
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Now that sources are associated with projects, remove the source
attribute from pipelines altogether.
This removes the occurance in tests fixtures as well as the element
from the pipeline configuration schema.
Change-Id: If47ecfcd5c5c82b30f6ee8890ed0766cfc88739e
Story: 2000953
This permits an operator to specify that a given pipeline should
never run a job with secrets. This may be used, for example, to
ensure that no one adds, say, the pypi-upload job to a check
pipeline and then uses that to expose credentials.
Change-Id: I606a76fe9ed19bb87d78f07195fb3950805e8726
Rightly the system in use is RSAES-OAEP, part of the PKCS#1 standard.
"PKCS#1" is not enough information to communicate to someone the
encryption scheme in use. Refer to the scheme Zuul uses as "PKCS#1-OAEP"
or "pkcs1-oaep" to clarify.
Change-Id: I74dcde6fa3756354ce65233c64c6189d1b241e90
When configuring jobs, decrypt secrets they reference. Pass the
resulting values to ansible variables.
Change-Id: Ibe2b6b84fdc0f4287e4dc1681218df2228f92db0
This adds secrets as a top-level config object, including a new
custom YAML tag to indicate encrypted data.
It also adds a script which encrypts data for use in tests.
Change-Id: I92a6bc048874f8aa4ebe0dd27180b253bede7370
It will be helpful to know which executor ansible-playbook is run
from so pass this info into vars.yaml.
Additionally, update our test_v3 playbook test to also validate our
other executor ansible variables.
Change-Id: I22091c8e764ad519878e5d530e5bc72ffd2a4870
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
This replaces the job dependency tree with a graph so that we can
indicate that a job should wait until one or more jobs are complete
before starting.
Project pipeline job definitions are now a flat list, with each job
specifying its dependencies as the job attribute 'dependencies'.
Fixes bug #1166937.
Signed-off-by: Fredrik Medley <fredrik.medley@autoliv.com>
Signed-off-by: Fredrik Medley <fredrik.medley@gmail.com>
Signed-off-by: James E. Blair <jeblair@redhat.com>
Co-Authored-By: James E. Blair <jeblair@redhat.com>
Change-Id: I921940cafeea0738c39deb99357cfd7c91592359
Because we want jobs to know something about the provider they are
running on, expose nodepool variables in the inventory file.
Change-Id: I18c8b414b1bbb114d55d21c5ae77d6348b3e9080
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Plumb through support for timeout for jobs. By default, we don't
support any timeout, which means jobs live forever.
Change-Id: Ice4fedffc6086676f54da0f06630a0ff7ad7d916
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
This adds support for Ansible roles in Zuul-managed repos. It
is currently limited to repos within the same source, which is
something we should fix.
We also plan to add support for roles from Ansible Galaxy in a
future change.
Change-Id: I7af4dc1333db0dcb9d4a8318a4a95b9564cd1dd8
This allows jobs to specify pre and post playbooks. Jobs which inherit
from parents or variants add their pre and post playbooks to their
parents in onion fashion -- the outermost pre playbooks run first and post
playbooks run last.
Change-Id: Ic844dcac77d87481534745a220664d72be2ffa7c
This replaces the stubbed-out 'hello world' Ansible playbook with
an implementation which actually runs the corresponding playbook
defined in the repo where the job is defined.
Change-Id: I73a6b3b067c7d61bb2a2b2140ab98c4944a6adfe
Story: 2000772
James E. Blair