Jump to: navigation, search

Integration/Test/Running System Tests

Triggering System Tests With Commit Message Keyword

You can trigger all of the system tests by adding a special gerrit keyword in your git commit message.

This link describes the details and considerations when using this.

Running System Tests Using Custom Distribution Built From Multiple Patches

In addition to triggering all system tests with a single patch, you can use the multipatch job to create a custom distribution with multiple patches across multiple projects. Functionally, you could provide just a single patch and get the same functionality as the above "patch test" would give you. The usefulness of this multipatch job comes from, well, building multiple unmerged patches from different projects and to understand the combined effects on system test. It should be noted that multiple patches can be used from the same project as well.

The job will run all system tests, which takes several hours (or longer) so please use with discretion.

The jobs each have a build parameter called PATCHES_TO_BUILD. This is a comma separated list of project[=checkout][:cherry-pick]* values. Please note that the patch info does not include the refs/changes string that we do use in other jenkins parameters. To be clear, here is an example:


The above would do the following:

  • check out one patch 30045/2 from odlparent
  • cherry pick 26853/25 on top of yangtools
  • check out 29761/5 from controller and cherry pick 29645/6 on top of that
  • cherry pick both 30239/1 30059/2 on top of bgpcep

Each repo is cloned, and patches checked out and cherry-picked as needed. Finally, distribution is cloned. A parent pom is created with each project as a module and then built. The result is a custom distribution. That distribution is passed to the distribution-test job. It should also be noted that you can provide a patch from the distribution project itself, if you have the need. If no distribution patch is provided, it will just use the head of the branch for that job.

The script that does this work can be used locally for your own purposes. Pull the script and set the PATCHES_TO_BUILD environment variable as needed. That should be all that is required.

# One enhancement we hope to come soon is to be able to specify a subset of CSIT jobs to trigger instead of the
# whole list. This could shorten the run time and allow us to narrow the focus as needed.
# In the meantime, if you only want to use this patch to run a few CSIT jobs (or even none) you can push
# it (integration-multipatch-test-{branch}) to the sandbox along with integration-distribution-test-{branch}
# and any CSIT jobs. Then you can configure the distribution-test job to only run those CSIT jobs you are
# interested in. #

Using The Sandbox To Run System Tests

Using JJB and the RelEng/Builder project, you can upload your job to the sandbox to debug and validate. More info can be found here.

Running System Tests Locally

<coming soon: some info here already, and some info from email exchanges to be added>