diff options
authorIan Wienand <>2018-12-12 16:43:59 +1100
committerIan Wienand <>2018-12-18 07:39:19 +1100
commit990fe95337dc1462471bcca83229243e5ed2afc1 (patch)
parent2ea7a1b6bdf69d5a79658aea04a1f6d596e95d0a (diff)
Add a note on testing trusted roles
Add a general note on testing, and specifically on how to use test roles for testing trusted roles in the gate. Change-Id: Idf84bc56effbb21f7b7a82703f398fb203c3694b
Notes (review): Code-Review+2: Tobias Henkel <> Code-Review+2: Joshua Hesketh <> Code-Review+2: Jens Harbott (frickler) <> Workflow+1: Jens Harbott (frickler) <> Verified+2: Zuul Submitted-by: Zuul Submitted-at: Tue, 18 Dec 2018 14:26:46 +0000 Reviewed-on: Project: openstack-infra/zuul-jobs Branch: refs/heads/master
1 files changed, 36 insertions, 0 deletions
diff --git a/doc/source/policy.rst b/doc/source/policy.rst
index dfb8c89..ef92aac 100644
--- a/doc/source/policy.rst
+++ b/doc/source/policy.rst
@@ -70,6 +70,42 @@ as ``example_role_variable``; e.g.
70 vars: 70 vars:
71 example_role_variable: 'something' 71 example_role_variable: 'something'
72 72
76`zuul-jobs` is often consumed from the master branch and many parts of
77`zuul-jobs` are involved in base setup. Thus bad changes have a
78larger than usual potential to quickly produce global problems.
79Demonstrated testing of changes is very important and is requested of
80all proposed changes.
82Since many roles in `zuul-jobs` are run from trusted jobs that run
83directly on the executor, often changes are not self-testing. In such
84cases, it may be possible to demonstrate sufficient testing via
85external methods. This should be noted carefully in the review.
87To use the OpenStack gate, you should develop your change as usual
88with as much testing as possible. Once you have pushed the main
89review, you should clone the changes to the role being tested to a
90``test-<rolename>`` role in a new change (there may already be a
91``test-<rolename>`` if someone has done this before you; in this case,
92update it with your change). Then rebase this testing change *before*
93your main change (the commit message should say something along the
94lines of "This change is for pre-testing of change I...").
96Reviewers can commit this change without affecting production jobs.
97You then need to look at the ``playbooks/base-test/`` files in
98``project-config`` and make sure they are using the
99``test-<rolename>`` role, which should now be committed (in some
100cases, if it has been done before, it may already be; otherwise
101propose a change to swap the role in ``base-test`` that Depends-On
102your ``test-<rolename>`` addition). You can then reparent a
103do-not-merge job to ``base-test`` and your changes will be executed.
105After this, the actual change can be merged. Note that after this,
106the ``test-<rolename>`` and ``<rolename>`` roles will be identical,
107which is how it should remain until the next proposed change.
73.. _zuul-announce: 109.. _zuul-announce:
74.. _zuul-discuss: 110.. _zuul-discuss:
75 111