[openstack-dev] [neutron] [third-party-testing] Which patchset triggered the test

Jay Pipes jaypipes at gmail.com
Mon Jan 20 22:40:36 UTC 2014

On Mon, 2014-01-20 at 14:26 -0500, Mohammad Banikazemi wrote:
> Have a question regarding the Jenkins/Gerrit setup for third party
> testing setups.
> When Jenkins get triggered by a patchset through the Gerrit trigger
> plug-in, you can execute a set of shell scripts. How do you get the
> information about the patchset that triggered the test? In particular,
> in your scripts how do you figure out which patchset triggered the
> test. Here is why I am asking this question:
> During our earlier IRC calls we said, one approach for testing would
> be using devstack to install OpenStack and run appropriate tests. The
> devstack stack.sh brings in the master branch without the patchset
> which triggered the test. How do I access the patchset I want to test?
> Am I missing something here?

As mentioned by a previous poster, the Gerrit plugin populates some
environment variables that you may use in your scripts in order to fetch
and check out the appropriate git branch and SHA1 that corresponds to
the changeset and patch number.

For a great example of how this is done in the upstream CI system for
the gate, check out the devstack-gate project and the setup_workspace()
[1] Bash function. This function calls the setup_project() [2] Bash
function for each project that is registered for devstack to construct.
The devstack-gate-wrap.sh script is responsible for enumerating all of
the projects that devstack will install [3].

setup_project() is responsible for setting the git checkouts for all of
the OpenStack projects involved in the devstack installation --
including the project for which the triggering changeset is for. The
function calls git clone on the project's upstream cgit repository URI
[4], and then calls git fetch on the branch and SHA1 (ref) that
represents the proposed changeset in Gerrit.

In the setup_project() function, you will notice the use of the
environment variables $ZUUL_BRANCH and $ZUUL_REF. The upstream CI system
uses a Python service called Zuul [6] to manage the graph of in-progress
changesets that are currently going through the gate testing process.
While your in-house testing platform won't likely be using Zuul, the
Gerrit plugin [7] to Jenkins *will* have a similar $GERRIT_BRANCH and
$GERRIT_REFSPEC environment variable that you can use in your scripts
that contains the git ref you can use in scripts in your in-house
testing in the same way that devstack-gate uses $ZUUL_BRANCH and

Finally, once your in-house setup script has constructed the devstack
environment -- including all of the git checkout'd code trees, then to
run the Neutron testing suite, simply do the following:

cd /opt/stack/new/devstack
sudo -H -u stack ./tools/configure_tempest.sh
cd /opt/stack/new/tempest
sudo -H -u tempest tox -esmoke-serial

How did I know to run the above commands? Well, because that's what the
check-tempest-dsvm-neutron-isolated (configured in the
openstack-infra/config project here: [8]) test runs in the
devstack-gate.sh script here: [9] :)

All the best,

p.s. I'm putting together some documentation walking through how these
many CI systems and gate projects all work together to configure and run
tests against a devstack environment in the gate. I should be done by
Wednesday or Thursday and will publish a link to the ML. Hopefully, the
instructions will be helpful for Cinder, Neutron, and other contributors
looking to set up 3rd party driver verification testing.

[6] http://ci.openstack.org/zuul.html
[7] https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger

More information about the OpenStack-dev mailing list