+.. _odl-jenkins:
+
Jenkins
=======
Please note that the combination of a Packer definitions from `vars`, `templates`
and the `provision` scripts is what defines a given minion. For instance, a minion
-may be defined as `centos7-java-builder` which is a combination of Packer OS image
+may be defined as `centos7-builder` which is a combination of Packer OS image
definitions from `vars/centos.json`, Packer template definitions from
-`templates/java-buidler.json` and spinup scripts from `provision/java-builder.sh`.
+`templates/builder.json` and spinup scripts from `provision/builder.sh`.
This combination provides the full definition of the realized minion.
Jenkins starts a minion using the latest image which is built and linked into the
accounts in the cloud so should ensure consistent performance.
.. list-table:: Flavors
- :widths: auto"
- :header-rows: 1"
+ :widths: auto
+ :header-rows: 1
* - Instance Type
- CPUs
- Memory
- * - v1-performance-1
+ * - odl-standard-1
- 1
- 4
- * - v1-performance-2
+ * - odl-standard-2
- 2
- 8
- * - v1-performance-4
+ * - odl-standard-4
- 4
- 16
- * - v1-performance-8
+ * - odl-standard-8
- 8
- 32
- * - v1-performance-16
+ * - odl-standard-16
- 16
- 64
+ * - odl-highcpu-2
+ - 2
+ - 2
+
+ * - odl-highcpu-4
+ - 4
+ - 4
+
+ * - odl-highcpu-8
+ - 8
+ - 8
+
Pool: ODLVEX
^^^^^^^^^^^^
<table class="table table-bordered">
<tr class="warning">
- <td><b>Jenkins Labels</b><br/> centos7-java-builder-2c-4g,
- centos7-java-builder-2c-8g, centos7-java-builder-4c-8g,
- centos7-java-builder-8c-8g, centos7-java-builder-4c-16g</td>
- <td><b>Minion Template names</b><br/> centos7-java-builder-2c-4g,
- centos7-java-builder-2c-4g, centos7-java-builder-2c-8g,
- centos7-java-builder-4c-8g, centos7-java-builder-8c-8g,
- centos7-java-builder-4c-16g</td>
+ <td><b>Jenkins Labels</b><br/>
+ centos7-builder-2c-1g,<br/>
+ centos7-builder-2c-2g,<br/>
+ centos7-builder-2c-8g,<br/>
+ centos7-builder-4c-4g,<br/>
+ centos7-builder-8c-8g,<br/>
+ centos7-autorelease-4c-16g
+ </td>
+ <td><b>Minion Template names</b><br/>
+ prd-centos7-builder-2c-1g,<br/>
+ prd-centos7-builder-2c-2g,<br/>
+ prd-centos7-builder-2c-8g,<br/>
+ prd-centos7-builder-4c-4g,<br/>
+ prd-centos7-builder-8c-8g,<br/>
+ prd-centos7-autorelease-4c-16g
<td><b>Packer Template</b><br/>
- releng/builder/packer/templates/java-builder.json</td>
+ releng/builder/packer/templates/builder.json</td>
<td><b>Spinup Script</b><br/>
releng/builder/jenkins-scripts/builder.sh</td>
</tr>
$ cat jjb/requirements.txt
-e git+https://git.openstack.org/openstack-infra/jenkins-job-builder@1.4.0#egg=jenkins-job-builder
+Updating releng/builder repo or global-jjb
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Follow these steps to update the releng/builder repo. The repo uses a submodule from
+a global-jjb repo so that common source can be shared across different projects. This
+requires updating the releng/builder repo periodically to pick up the changes. New
+versions of jjb could also require updating the releng/builder repo. Follow the
+previous steps earlier for updating jenkins-jobs using the
+`builder/jjb/requirements.txt <odl-jjb-requirements.txt_>`_ file. Ensure that the
+version listed in the file is the currently supported version, otherwise install a
+different version or simply upgrade using `pip install --upgrade jenkins-job-builder`.
+
+The example below assumes the user has cloned releng/builder to `~/git/releng/builder`.
+Update the repo, update the submodules and then submit a test to verify it works.
+
+.. code-block:: bash
+
+ cd ~/git/releng/builder
+ git checkout master
+ git pull
+ git submodule update --init --recursive
+ jenkins-jobs --conf jenkins.ini test jjb/ netvirt-csit-1node-openstack-queens-upstream-stateful-fluorine
+
Installing JJB Manually
-----------------------
</td>
</tr>
- <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">
- </td>
- </tr>
-
<tr class="warning">
<td><b>Job Template</b><br/>integration-patch-test-{stream}</td>
<td><b>Gerrit Trigger</b><br/>test-integration</td>
</li>
</td>
</tr>
+
+ <tr class="warning">
+ <td><b>Job Template</b><br/>integration-multipatch-test-{stream}</td>
+ <td><b>Gerrit Trigger</b><br/>multipatch-build</td>
+ </tr>
+ <tr>
+ <td colspan="2">
+ This job builds a list of patches provided in an specific order, and finally builds
+ a distribution from either provided patch or latest code in branch.
+ For example if someone leaves the following comment in a patch:
+ multipatch-build:controller=61/29761/5:45/29645/6,neutron=51/65551/4,netvirt:59/60259/17
+ the job will checkout controller patch 61/29761/5, cherry-pick 45/29645/6 and build controller,
+ checkout neutron patch 51/65551/4 and build neutron, checkout latest netvirt code,
+ cherry-pick 59/60259/17 and build netvirt, finally it will checkout latest distribution
+ code and build a distribution. The resulting distribution is stored in Nexus and the URL
+ is stored in a variable called BUNDLE_URL visible in the job console.
+ This job also accepts a gerrit topic, for example: multipatch-build:topic=binding-tlc-rpc,
+ in this case the job will find all patches in the topic binding-tlc-rpc for the projects
+ specified in the BUILD_ORDER parameter and will build all projects from the first a patch
+ has been found, for successive projects the branch HEAD is used if no patch is found.
+ The job uses patch numbers to sort patches in the same project.
+ Use multipatch-build-fast (vs multipatch-build) for building projects fast (-Pq).
+ This job should not alter Gerrit votes for a given patch, nor will do anything with the
+ given patch unless the patch is added to the build list.
+ </td>
+ </tr>
+
</table>
Maven Properties
Maven property
<sonar>true</sonar>.
+.. _odl-jenkins-sandbox:
+
Jenkins Sandbox
---------------
# Edit jenkins.ini with your username, API token and ODL's sandbox URL
$ cat jenkins.ini
<snip>
+ [job_builder]
+ retain_anchors=True
+
[jenkins]
user=<your ODL username>
password=<your ODL Jenkins sandbox API token>
JJB jobs <Testing Jobs_>`_ produce valid XML descriptions of Jenkins jobs you
can push them to the Jenkins sandbox.
+Add the --jobs-only (-j) option to push only jobs to Jenkins sandbox. Pushing
+views to Jenkins sandbox requires admin access.
+
.. important::
When pushing with `jenkins-jobs`, a log message with the number
.. code-block:: bash
# Don't push all jobs by omitting the final param! (ctrl+c to abort)
- jenkins-jobs --conf jenkins.ini update jjb/ <job-name>
+ jenkins-jobs --conf jenkins.ini update -j jjb/ <job-name>
Alternatively, you can push a job to the Jenkins sandbox with a special comment in a
releng/builder gerrit patch. The job will be based off of the code your patch is
jjb-deploy <job name>
+.. note::
+
+ Also note that wildcards can be used in <job name> which
+ will expand all jobs that exist for the pattern.
+
Running Jobs
^^^^^^^^^^^^