directly on the server.
Build Minions
-------------
+-------------
The Jenkins jobs are run on build minions (executors) which are created on an
as-needed basis. If no idle build minions are available a new VM is brought
label.
Adding New Components to the Minions
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If your project needs something added to one of the minions used during build
and test you can help us get things added faster by doing one of the following:
.. raw:: html
- <table border="1">
- <tr>
+ <table class="table table-bordered">
+ <tr class="warning">
<td><b>Jenkins Label</b><br/> dynamic_verify</td>
<td><b>Minion Template name</b><br/> centos7-builder</td>
<td><b>Vagrant Definition</b><br/> releng/builder/vagrant/basic-builder</td>
projects.
</td>
</tr>
- </table>
- <table border="1">
- <tr>
+ <tr class="warning">
<td><b>Jenkins Label</b><br/> dynamic_merge</td>
<td><b>Minion Template name</b><br/> centos7-builder</td>
<td><b>Vagrant Definition</b><br/> releng/builder/vagrant/basic-builder</td>
is used for all basic -merge and -integration- builds for projects.
</td>
</tr>
- </table>
- <table border="1">
- <tr>
+ <tr class="warning">
<td><b>Jenkins Label</b><br/> matrix_master</td>
<td><b>Minion Template name</b><br/> centos7-matrix</td>
<td><b>Vagrant Definition</b><br/> releng/builder/vagrant/basic-java-node</td>
anything but tying matrix jobs before the matrx defined label ties.
</td>
</tr>
- </table>
- <table border="1">
- <tr>
+ <tr class="warning">
<td><b>Jenkins Label</b><br/> dynamic_robot</td>
<td><b>Minion Template name</b><br/> centos7-robot</td>
<td><b>Vagrant Definition</b><br/> releng/builder/vagrant/integration-robotframework</td>
building components of OpenDaylight, only for executing robot tests.
</td>
</tr>
- </table>
- <table border="1">
- <tr>
+ <tr class="warning">
<td><b>Jenkins Label</b><br/> ubuntu_mininet</td>
<td><b>Minion Template name</b><br/> ubuntu-trusty-mininet</td>
<td><b>Vagrant Definition</b><br/> releng/builder/vagrant/ubuntu-mininet</td>
Basic Ubuntu system with ovs 2.0.2 and mininet 2.1.0
</td>
</tr>
- </table>
- <table border="1">
- <tr>
+ <tr class="warning">
<td><b>Jenkins Label</b><br/> ubuntu_mininet_ovs_23</td>
<td><b>Minion Template name</b><br/> ubuntu-trusty-mininet-ovs-23</td>
<td><b>Vagrant Definition</b><br/> releng/builder/vagrant/ubuntu-mininet-ovs-23</td>
Basic Ubuntu system with ovs 2.3 and mininet 2.2.1
</td>
</tr>
- </table>
- <table border="1">
- <tr>
+ <tr class="warning">
<td><b>Jenkins Label</b><br/> dynamic_controller</td>
<td><b>Minion Template name</b><br/> centos7-java</td>
<td><b>Vagrant Definition</b><br/> releng/builder/vagrant/basic-java-node</td>
building.
</td>
</tr>
- </table>
- <table border="1">
- <tr>
+ <tr class="warning">
<td><b>Jenkins Label</b><br/> dynamic_java</td>
<td><b>Minion Template name</b><br/> centos7-java</td>
<td><b>Vagrant Definition</b><br/> releng/builder/vagrant/basic-java-node</td>
See dynamic_controller as it is currently the same image.
</td>
</tr>
- </table>
- <table border="1">
- <tr>
+ <tr class="warning">
<td><b>Jenkins Label</b><br/> dynamic_java_8g</td>
<td><b>Minion Template name</b><br/> centos7-java-8g</td>
<td><b>Vagrant Definition</b><br/> releng/builder/vagrant/basic-java-node</td>
See dynamic_controller as it is currently the same image but with 8G of RAM.
</td>
</tr>
- </table>
- <table border="1">
- <tr>
+ <tr class="warning">
<td><b>Jenkins Label</b><br/> dynamic_devstack</td>
<td><b>Minion Template name</b><br/> centos7-devstack</td>
<td><b>Vagrant Definition</b><br/> releng/builder/vagrant/ovsdb-devstack</td>
other basic DevStack related bits installed.
</td>
</tr>
- </table>
- <table border="1">
- <tr>
+ <tr class="warning">
<td><b>Jenkins Label</b><br/> dynamic_docker</td>
<td><b>Minion Template name</b><br/> centos7-docker</td>
<td><b>Vagrant Definition</b><br/> releng/builder/vagrant/ovsdb-docker</td>
expressed interest in using it.
</td>
</tr>
- </table>
- <table border="1">
- <tr>
+ <tr class="warning">
<td><b>Jenkins Label</b><br/> gbp_trusty</td>
<td><b>Minion Template name</b><br/> gbp_trusty</td>
<td><b>Vagrant Definition</b><br/> releng/builder/vagrant/gbp-ubuntu-docker-ovs-node</td>
The OpenDaylight `RelEng/Builder <releng-builder-wiki_>`_ project provides
`jjb-templates`_ that can be used to define basic jobs.
-Verify Job Template
-^^^^^^^^^^^^^^^^^^^
-
-Trigger: **recheck**
-
-The Verify job template creates a Gerrit Trigger job that will trigger when a
-new patch is submitted to Gerrit.
-
-Verify jobs can be retriggered in Gerrit by leaving a comment that says
-**recheck**.
-
-Merge Job Template
-^^^^^^^^^^^^^^^^^^
-
-Trigger: **remerge**
-
-The Merge job template is similar to the Verify Job Template except it will
-trigger once a Gerrit patch is merged into the repo. It also automatically
-runs the Maven goals **source:jar** and **javadoc:jar**.
-
-This job will upload artifacts to `OpenDaylight's Nexus <odl-nexus_>`_ on completion.
-
-Merge jobs can be retriggered in Gerrit by leaving a comment that says
-**remerge**.
-
-Daily Job Template
-^^^^^^^^^^^^^^^^^^
-
-The Daily (or Nightly) Job Template creates a job which will run on a build on
-a Daily basis as a sanity check to ensure the build is still working day to
-day.
-
-Sonar Job Template
-^^^^^^^^^^^^^^^^^^
-
-Trigger: **run-sonar**
-
-This job runs Sonar analysis and reports the results to `OpenDaylight's Sonar
-dashboard <odl-sonar_>`_.
-
-The Sonar Job Template creates a job which will run against the master branch,
-or if BRANCHES are specified in the CFG file it will create a job for the
-**First** branch listed.
-
-.. note:: Running the "run-sonar" trigger will cause Jenkins to remove its
- existing vote if it's already -1'd or +1'd a comment. You will need to
- re-run your verify job (recheck) after running this to get Jenkins to
- re-vote.
-
-Integration Job Template
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-The Integration Job Template creates a job which runs when a project that your
-project depends on is successfully built. This job type is basically the same
-as a verify job except that it triggers from other Jenkins jobs instead of via
-Gerrit review updates. The dependencies that triger integration jobs are listed
-in your project.cfg file under the **DEPENDENCIES** variable.
-
-If no dependencies are listed then this job type is disabled by default.
-
-Distribution Test Job
-^^^^^^^^^^^^^^^^^^^^^
-
-Trigger: **test-distribution**
-
-This job builds a distrbution against your patch, passes distribution sanity test
-and reports back the results to Gerrit. Leave a comment with trigger keyword above
-to activate it for a particular patch.
-
-This job is maintained by the Integration/Test (`integration-test-wiki`_) project.
+The *Gerrit Trigger* listed in the jobs are keywords that can be used to
+trigger the job to run manually by simply leaving a comment in Gerrit for the
+patch you wish to trigger against.
-.. note:: Running the "test-distribution" trigger will cause Jenkins to remove
- it's existing vote if it's already -1 or +1'd a comment. You will need
- to re-run your verify job (recheck) after running this to get Jenkins
- to put back the correct vote.
+All jobs have a default build-timeout value of 360 minutes (6 hrs) but can be
+overrided via the opendaylight-infra-wrappers' build-timeout property.
-Patch Test Job
-^^^^^^^^^^^^^^
-
-Trigger: **test-integration**
-
-This job runs a full integration test suite against your patch and reports
-back the results to Gerrit. Leave a comment with trigger keyword above to activate it
-for a particular patch.
-
-This job is maintained by the Integration/Test (`integration-test-wiki`_) project.
-
-.. note:: Running the "test-integration" trigger will cause Jenkins to remove
- it's existing vote if it's already -1 or +1'd a comment. You will need
- to re-run your verify job (recheck) after running this to get Jenkins
- to put back the correct vote.
-
-Some considerations when using this job:
-
-* The patch test verification takes some time (~2 hours) + consumes a lot of
- resources so it is not meant to be used for every patch.
-* The system tests for master patches will fail most of the times because both
- code and test are unstable during the release cycle (should be good by the
- end of the cycle).
-* Because of the above, patch test results typically have to be interpreted by
- system test experts. The Integration/Test (`integration-test-wiki`_) project
- can help with that.
-
-
-Autorelease Validate Job
-^^^^^^^^^^^^^^^^^^^^^^^^
+.. raw:: html
-Trigger: **revalidate**
+ <table class="table table-bordered">
+ <tr class="warning">
+ <td><b>Job Template</b><br/>{project}-distribution-{stream}</td>
+ <td><b>Gerrit Trigger</b><br/>test-distribution</td>
+ </tr>
+ <tr>
+ <td colspan="2">
+ This job builds a distrbution against your patch, passes distribution sanity test
+ and reports back the results to Gerrit. Leave a comment with trigger keyword above
+ to activate it for a particular patch.
+
+ This job is maintained by the <a href="https://wiki.opendaylight.org/view/Integration/Test">Integration/Test</a>
+ project.
+
+ <div class="admonition note">
+ <p class="first admonition-title">Note</p>
+ <p>
+ Running the "test-distribution" trigger will cause Jenkins to
+ remove it's existing vote if it's already -1 or +1'd a comment.
+ You will need to re-run your verify job (recheck) after running
+ this to get Jenkins to put back the correct vote.
+ </p>
+ </div>
+ </td>
+ </tr>
-This job runs the PROJECT-validate-autorelease-BRANCH job which is used as a
-quick sanity test to ensure that a patch does not depend on features that do
-not exist in the current release.
+ <tr class="warning">
+ <td><b>Job Template</b><br/>{project}-integration-{stream}</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td colspan="2">
+ The Integration Job Template creates a job which runs when a project that your
+ project depends on is successfully built. This job type is basically the same
+ as a verify job except that it triggers from other Jenkins jobs instead of via
+ Gerrit review updates. The dependencies that triger integration jobs are listed
+ in your project.cfg file under the <b>DEPENDENCIES</b> variable.
+
+ If no dependencies are listed then this job type is disabled by default.
+ </td>
+ </tr>
-The **revalidate** trigger is useful in cases where a project's verify job
-passed however validate failed due to infra problems or intermittent issues.
-It will retrigger just the validate-autorelease job.
+ <tr class="warning">
+ <td><b>Job Template</b><br/>{project}-merge-{stream}</td>
+ <td><b>Gerrit Trigger</b><br/>remerge</td>
+ </tr>
+ <tr>
+ <td colspan="2">
+ The Merge job template is similar to the Verify Job Template except
+ it will trigger once a Gerrit patch is merged into the repo. It
+ also automatically runs the Maven goals <b>source:jar</b> and
+ <b>javadoc:jar</b>.
+
+ This job will upload artifacts to OpenDaylight's
+ <a href="https://nexus.opendaylight.org">Nexus</a> on completion.
+ </td>
+ </tr>
-Python Verify Job
-^^^^^^^^^^^^^^^^^
+ <tr class="warning">
+ <td><b>Job Template</b><br/>{project}-sonar</td>
+ <td><b>Gerrit Trigger</b><br/>run-sonar</td>
+ </tr>
+ <tr>
+ <td colspan="2">
+ This job runs Sonar analysis and reports the results to
+ OpenDaylight's <a href="https://sonar.opendaylight.org">Sonar</a>
+ dashboard.
+
+ The Sonar Job Template creates a job which will run against the
+ master branch, or if BRANCHES are specified in the CFG file it will
+ create a job for the <b>First</b> branch listed.
+
+ <div class="admonition note">
+ <p class="first admonition-title">Note</p>
+ <p>
+ Running the "run-sonar" trigger will cause Jenkins to remove
+ its existing vote if it's already -1'd or +1'd a comment. You
+ will need to re-run your verify job (recheck) after running
+ this to get Jenkins to re-vote.
+ </p>
+ </div>
+ </td>
+ </tr>
-Trigger: **recheck** | **revalidate**
+ <tr class="warning">
+ <td><b>Job Template</b><br/>{project}-validate-autorelease-{stream}</td>
+ <td><b>Gerrit Trigger</b><br/>recheck | reverify</td>
+ </tr>
+ <tr>
+ <td colspan="2">
+ This job runs the PROJECT-validate-autorelease-BRANCH job which is
+ used as a quick sanity test to ensure that a patch does not depend on
+ features that do not exist in the current release.
+
+ The <b>revalidate</b> trigger is useful in cases where a project's
+ verify job passed however validate failed due to infra problems or
+ intermittent issues. It will retrigger just the validate-autorelease
+ job.
+ </td>
+ </tr>
-This job template can be used by a project that is Python based. It simply
-installs a python virtualenv and uses tox to run tests. When using the template
-you need to provide a {toxdir} which is the path relative to the root of the
-project repo containing the tox.ini file.
+ <tr class="warning">
+ <td><b>Job Template</b><br/>{project}-verify-{stream}</td>
+ <td><b>Gerrit Trigger</b><br/>recheck | reverify</td>
+ </tr>
+ <tr>
+ <td colspan="2">
+ The Verify job template creates a Gerrit Trigger job that will
+ trigger when a new patch is submitted to Gerrit.
+ </td>
+ </tr>
-Node Verify Job
-^^^^^^^^^^^^^^^^^
+ <tr class="warning">
+ <td><b>Job Template</b><br/>{project}-verify-node-{stream}</td>
+ <td><b>Gerrit Trigger</b><br/>recheck | reverify</td>
+ </tr>
+ <tr>
+ <td colspan="2">
+ This job template can be used by a project that is NodeJS based. It
+ simply installs a python virtualenv and uses that to install nodeenv
+ which is then used to install another virtualenv for nodejs. It then
+ calls <b>npm install</b> and <b>npm test</b> to run the unit tests.
+ When using this template you need to provide a {nodedir} and
+ {nodever} containing the directory relative to the project root
+ containing the nodejs package.json and version of node you wish to
+ run tests with.
+ </td>
+ </tr>
-Trigger: **recheck** | **revalidate**
+ <tr class="warning">
+ <td><b>Job Template</b><br/>{project}-verify-python-{stream}</td>
+ <td><b>Gerrit Trigger</b><br/>recheck | reverify</td>
+ </tr>
+ <tr>
+ <td colspan="2">
+ This job template can be used by a project that is Python based. It
+ simply installs a python virtualenv and uses tox to run tests. When
+ using the template you need to provide a {toxdir} which is the path
+ relative to the root of the project repo containing the tox.ini file.
+ </td>
+ </tr>
-This job template can be used by a project that is NodeJS based. It simply
-installs a python virtualenv and uses that to install nodeenv which is then
-used to install another virtualenv for nodejs. It then calls **npm install**
-and **npm test** to run the unit tests. When using this template you need to
-provide a {nodedir} and {nodever} containing the directory relative to the
-project root containing the nodejs package.json and version of node you wish to
-run tests with.
+ <tr class="warning">
+ <td><b>Job Template</b><br/>integration-patch-test-{stream}</td>
+ <td><b>Gerrit Trigger</b><br/>test-integration</td>
+ </tr>
+ <tr>
+ <td colspan="2">
+ This job runs a full integration test suite against your patch and
+ reports back the results to Gerrit. Leave a comment with trigger
+ keyword above to activate it for a particular patch.
+
+ It then spawns the list of jobs in csit-list defined
+ <a href="https://git.opendaylight.org/gerrit/gitweb?p=releng/builder.git;a=blob;f=jjb/integration/integration-test-jobs.yaml">here</a>.
+
+ This job is maintained by the <a href="https://wiki.opendaylight.org/view/Integration/Test">Integration/Test</a>
+ project.
+
+ <div class="admonition note">
+ <p class="first admonition-title">Note</p>
+ <p>
+ Running the "test-integration" trigger will cause Jenkins to remove
+ it's existing vote if it's already -1 or +1'd a comment. You will need
+ to re-run your verify job (recheck) after running this to get Jenkins
+ to put back the correct vote.
+ </p>
+ </div>
+
+ Some considerations when using this job:
+ <ul>
+ <li>
+ The patch test verification takes some time (~2 hours) + consumes a lot of
+ resources so it is not meant to be used for every patch.
+ </li>
+ <li>
+ The system tests for master patches will fail most of the times because both
+ code and test are unstable during the release cycle (should be good by the
+ end of the cycle).
+ </li>
+ <li>
+ Because of the above, patch test results typically have to be interpreted by
+ system test experts. The <a href="https://wiki.opendaylight.org/view/Integration/Test">Integration/Test</a>
+ project can help with that.
+ </li>
+ </td>
+ </tr>
+ </table>
Basic Job Configuration
-----------------------
MVN_GOALS: clean install javadoc:aggregate -DrepoBuild -Dmaven.repo.local=$WORKSPACE/.m2repo -Dorg.ops4j.pax.url.mvn.localRepository=$WORKSPACE/.m2repo
MVN_OPTS: -Xmx1024m -XX:MaxPermSize=256m
DEPENDENCIES: aaa,controller,yangtools
- ARCHIVE_ARTIFACTS: *.logs, *.patches
+ ARCHIVE_ARTIFACTS: "*.logs, *.patches"
.. note:: `STREAMS <streams-design-background_>`_ is a list of branches you want
JJB to generate jobs for.
<snip>
To get your API token, `login to the Jenkins **sandbox** instance
-<jenkins-sandbox-login_>`_ (_not
-the main master Jenkins instance, different tokens_), go to your user page (by
+<jenkins-sandbox-login_>`_ (*not
+the main master Jenkins instance, different tokens*), go to your user page (by
clicking on your username, for example), click "Configure" and then "Show API
Token".
Code Review / releng / builder.git / blobdiff