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
-^^^^^^^^^^^^^^^^^^^^^
+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.
-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.
-
-.. 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.
-
-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
-----------------------
Code Review / releng / builder.git / commitdiff