X-Git-Url: https://git.opendaylight.org/gerrit/gitweb?a=blobdiff_plain;f=docs%2Fjenkins.rst;h=e8a0c1962de7d60a661f0ac4334d9953beb9654f;hb=d46ff39d84c924556690dd39ffad7efa08a83856;hp=d1d9cd79d0caad7981cc3327efa9f1298e20b7a8;hpb=9d1353bee8c6b392ccece37ab54108abe4c7e4bd;p=releng%2Fbuilder.git diff --git a/docs/jenkins.rst b/docs/jenkins.rst index d1d9cd79d..e8a0c1962 100644 --- a/docs/jenkins.rst +++ b/docs/jenkins.rst @@ -1,3 +1,5 @@ +.. _odl-jenkins: + Jenkins ======= @@ -16,50 +18,86 @@ Sections: New Project Quick Start ----------------------- -.. note:: - - We will be revamping releng/builder in the near future to simplify - the below process. - This section attempts to provide details on how to get going as a new project quickly with minimal steps. The rest of the guide should be read and understood by those who need to create and contribute new job types that is not already covered by the existing job templates provided by OpenDaylight's JJB repo. As a new project you will be mainly interested in getting your jobs to appear -in the jenkins-master_ silo and this can be achieved by simply creating 2 files -project.cfg and project.yaml in the releng/builder project's jjb directory. +in the jenkins-master_ silo and this can be achieved by simply creating a +.yaml in the releng/builder project's jjb directory. .. code-block:: bash - git clone https://git.opendaylight.org/gerrit/releng/builder + git clone --recursive https://git.opendaylight.org/gerrit/releng/builder cd builder mkdir jjb/ +.. note: + + releng/global-jjb is a submodule of releng/builder repository which + requires a git submodule update --init or using --recursive with git clone. + `releng-global-jjb`_ + Where should be the same name as your project's git repo in -Gerrit. So if your project is called "aaa" then create a new jjb/aaa directory. +Gerrit. If your project is called "aaa" then create a new jjb/aaa directory. Next we will create .yaml as follows: - # REMOVE THIS LINE IF YOU WANT TO CUSTOMIZE ANYTHING BELOW +.. code-block:: yaml -That's right all you need is the above comment in this file. Jenkins will -automatically regenerate this file when your patch is merged so we do not need -to do anything special here. + --- + - project: + name: -carbon + jobs: + - '{project-name}-clm-{stream}' + - '{project-name}-integration-{stream}' + - '{project-name}-merge-{stream}' + - '{project-name}-verify-{stream}-{maven}-{jdks}' + + project: '' + project-name: '' + stream: carbon + branch: 'master' + jdk: openjdk8 + jdks: + - openjdk8 + maven: + - mvn33: + mvn-version: 'mvn33' + mvn-settings: '-settings' + mvn-goals: 'clean install -Dmaven.repo.local=/tmp/r -Dorg.ops4j.pax.url.mvn.localRepository=/tmp/r' + mvn-opts: '-Xmx1024m -XX:MaxPermSize=256m' + dependencies: 'odlparent-merge-{stream},yangtools-merge-{stream},controller-merge-{stream}' + email-upstream: '[] [odlparent] [yangtools] [controller]' + archive-artifacts: '' + + - project: + name: -sonar + jobs: + - '{project-name}-sonar' + + project: '' + project-name: '' + branch: 'master' + mvn-settings: '-settings' + mvn-goals: 'clean install -Dmaven.repo.local=/tmp/r -Dorg.ops4j.pax.url.mvn.localRepository=/tmp/r' + mvn-opts: '-Xmx1024m -XX:MaxPermSize=256m' + +Replace all instances of with the name of your project. This will +create the jobs with the default job types we recommend for Java projects. If +your project is participating in the simultanious-release and ultimately will +be included in the final distribution, it is required to add the following job +types into the job list for the release you are participating. -Next we will create .cfg as follows: .. code-block:: yaml - STREAMS: - - boron: - branch: master - jdks: openjdk8 - DEPENDENCIES: odlparent,controller,yangtools + - '{project-name}-distribution-check-{stream}' + - '{project-name}-validate-autorelease-{stream}' -This is the minimal required CFG file contents and is used to auto-generate the -YAML file. If you'd like to explore the additional tweaking options available -please refer to the `Tuning Templates`_ section. +If you'd like to explore the additional tweaking options available +please refer to the `Jenkins Job Templates`_ section. Finally we need to push these files to Gerrit for review by the releng/builder team to push your jobs to Jenkins. @@ -87,8 +125,7 @@ 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 up. This process can take up to 2 minutes. Once the build minion has finished a -job, it will remain online for 45 minutes before shutting down. Subsequent -jobs will use an idle build minion if available. +job, it will be destroyed. Our Jenkins master supports many types of dynamic build minions. If you are creating custom jobs then you will need to have an idea of what type of minions @@ -100,104 +137,152 @@ 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: +If your project needs something added to one of the minions, you can help us +get things added faster by doing one of the following: -* Submit a patch to RelEng/Builder for the `spinup-scripts`_ that - configures your new piece of software. -* Submit a patch to RelEng/Builder for the Vagrant template's bootstrap.sh in - the `vagrant-definitions`_ directory that configures your new piece of - software. +* Submit a patch to RelEng/Builder for the appropriate `jenkins-scripts` + definition which configure software during minion boot up. +* Submit a patch to RelEng/Builder for the `packer/provision` scripts that + configures software during minion instance imaging. +* Submit a patch to RelEng/Builder for the Packer's templates in + the `packer/templates` directory that configures a new instance definition + along with changes in `packer/provision`. Going the first route will be faster in the short term as we can inspect the changes and make test modifications in the sandbox to verify that it works. -The second route, however, is better for the community as a whole as it will -allow others that utilize our Vagrant setups to replicate our systems more +.. note:: + + The first route may add additional setup time considering this is run every + time the minion is booted. + +The second and third routes, however, is better for the community as a whole as +it will allow others to utilize our Packer setups to replicate our systems more closely. It is, however, more time consuming as an image snapshot needs to be -created based on the updated Vagrant definition before it can be attached to -the sandbox for validation testing. +created based on the updated Packer definitions before it can be attached to the +Jenkins configuration on sandbox for validation testing. In either case, the changes must be validated in the sandbox with tests to make sure that we don't break current jobs and that the new software features are operating as intended. Once this is done the changes will be merged and -the updates applied to the RelEng Jenkins production silo. - -Please note that the combination of a Vagrant minion snapshot and a Jenkins -spinup script is what defines a given minion. For instance, a minion may be -defined by the `vagrant-basic-java-node`_ Vagrant definition -and the `spinup-scripts-controller.sh`_ Jenkins spinup script -(as the dynamic\_controller minion is). The pair provides the full definition of -the realized minion. Jenkins starts a minion using the last-spun Vagrant snapshot -for the specified definition. Once the base Vagrant instance is online Jenkins -checks out the RelEng/Builder repo on it and executes two scripts. The first is -`spinup-scripts-basic_settings.sh`_, which is a baseline for all of the minions. -The second is -the specialized spinup script, which handles any system updates, new software -installs or extra environment tweaks that don't make sense in a snapshot. After -all of these scripts have executed Jenkins will finally attach the minion as an -actual minion and start handling jobs on it. - -Pool: ODLRPC -^^^^^^^^^^^^^^^^^^^ +the updates applied to the RelEng Jenkins production silo. Any changes to +files under `releng/builder/packer` will be validated and images would be built +triggered by verify-packer and merge-packer jobs. + +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-builder` which is a combination of Packer OS image +definitions from `vars/centos.json`, Packer template definitions from +`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 +Jenkins configuration. Once the base instance is online Jenkins checks out the +RelEng/Builder repo on it and executes two scripts. The first is +`provision/baseline.sh`, which is a baseline for all of the minions. + +The second is the specialized script, which handles any system updates, +new software installs or extra environment tweaks that don't make sense in a +snapshot. Examples could include installing new package or setting up a virtual +environment. Its imperative to ensure modifications to these spinup scripts have +considered time taken to install the packages, as this could increase the build +time for every job which runs on the image. After all of these scripts have +executed Jenkins will finally attach the minion as an actual minion and start +handling jobs on it. + +Flavors +^^^^^^^ + +Performance flavors come with dedicated CPUs and are not shared with other +accounts in the cloud so should ensure consistent performance. + +.. list-table:: Flavors + :widths: auto + :header-rows: 1 + + * - Instance Type + - CPUs + - Memory + + * - odl-standard-1 + - 1 + - 4 + + * - odl-standard-2 + - 2 + - 8 + + * - odl-standard-4 + - 4 + - 16 + + * - odl-standard-8 + - 8 + - 32 + + * - odl-standard-16 + - 16 + - 64 + + * - odl-highcpu-2 + - 2 + - 2 + + * - odl-highcpu-4 + - 4 + - 4 + + * - odl-highcpu-8 + - 8 + - 8 + +Pool: ODLVEX +^^^^^^^^^^^^ .. raw:: html - - - - - - - - - - - - - - - - - - - - - - - - + + - - - - + + + + - - - - - - - - - - - - - - - - - - - - - - - - + + + + - - - - + + + + - - - - + + + + - - - - + + + + - - - - + + + + - - - - + + + + +
Jenkins Label
dynamic_verify
Minion Template name
centos7-builder
Vagrant Definition
releng/builder/vagrant/basic-builder
Spinup Script
releng/builder/jenkins-scripts/builder.sh
- A CentOS 7 huild minion. This system has OpenJDK 1.7 (Java7) and OpenJDK - 1.8 (Java8) installed on it along with all the other components and - libraries needed for building any current OpenDaylight project. This is - the label that is used for all basic -verify and -daily- builds for - projects. -
Jenkins Label
dynamic_merge
Minion Template name
centos7-builder
Vagrant Definition
releng/builder/vagrant/basic-builder
Spinup Script
releng/builder/jenkins-scripts/builder.sh
- See dynamic_verify (same image on the back side). This is the label that - is used for all basic -merge and -integration- builds for projects. + Jenkins Labels
+ centos7-builder-2c-1g,
+ centos7-builder-2c-2g,
+ centos7-builder-2c-8g,
+ centos7-builder-4c-4g,
+ centos7-builder-8c-8g,
+ centos7-autorelease-4c-16g
Jenkins Label
matrix_master
Minion Template name
centos7-matrix
Vagrant Definition
releng/builder/vagrant/basic-java-node
Spinup Script
releng/builder/jenkins-scripts/matrix.sh
Minion Template names
+ prd-centos7-builder-2c-1g,
+ prd-centos7-builder-2c-2g,
+ prd-centos7-builder-2c-8g,
+ prd-centos7-builder-4c-4g,
+ prd-centos7-builder-8c-8g,
+ prd-centos7-autorelease-4c-16g +
Packer Template
+ releng/builder/packer/templates/builder.json
Playbook
+ releng/builder/packer/common-packer/provision/baseline.yaml
- This is a very minimal system that is designed to spin up with 2 build - instances on it. The purpose is to have a location that is not the - Jenkins master itself for jobs that are executing matrix operations - since they need a director location. This image should not be used for - anything but tying matrix jobs before the matrx defined label ties. + CentOS 7 build minion configured with OpenJDK 1.7 (Java7) and OpenJDK + 1.8 (Java8) along with all the other components and libraries needed + for building any current OpenDaylight project. This is the label that + is used for all basic verify, merge and daily builds for + projects.
Jenkins Label
dynamic_robot
Minion Template name
centos7-robot
Vagrant Definition
releng/builder/vagrant/integration-robotframework
Spinup Script
releng/builder/jenkins-scripts/robot.sh
Jenkins Labels
centos7-robot-2c-2g
Minion Template names
centos7-robot-2c-2g
Packer Template
+ releng/builder/packer/templates/robot.json
Playbook
releng/builder/packer/provision/robot.yaml
- A CentOS 7 minion that is configured with OpenJDK 1.7 (Java7), OpenJDK + CentOS 7 minion configured with OpenJDK 1.7 (Java7), OpenJDK 1.8 (Java8) and all the current packages used by the integration project for doing robot driven jobs. If you are executing robot framework jobs then your job should be using this as the minion that @@ -207,76 +292,50 @@ Pool: ODLRPC
Jenkins Label
ubuntu_mininet
Minion Template name
ubuntu-trusty-mininet
Vagrant Definition
releng/builder/vagrant/ubuntu-mininet
Spinup Script
releng/builder/jenkins-scripts/mininet-ubuntu.sh
- Basic Ubuntu system with ovs 2.0.2 and mininet 2.1.0 -
Jenkins Label
ubuntu_mininet_ovs_23
Minion Template name
ubuntu-trusty-mininet-ovs-23
Vagrant Definition
releng/builder/vagrant/ubuntu-mininet-ovs-23
Spinup Script
releng/builder/jenkins-scripts/mininet-ubuntu.sh
- Basic Ubuntu system with ovs 2.3 and mininet 2.2.1 -
Jenkins Label
dynamic_controller
Minion Template name
centos7-java
Vagrant Definition
releng/builder/vagrant/basic-java-node
Spinup Script
releng/builder/jenkins-scripts/controller.sh
Jenkins Labels
ubuntu1604-mininet-ovs-25-2c-2g
Minion Template names
ubuntu1604-mininet-ovs-25-2c-2g
Packer Template
releng/builder/packer/templates/mininet-ovs-2.5.json
Playbook
releng/builder/packer/provision//mininet-ovs-2.5.yaml
- A CentOS 7 minion that has the basic OpenJDK 1.7 (Java7) and OpenJDK - 1.8 (Java8) installed and is capable of running the controller, not - building. + Basic Ubuntu 16.04 (Xenial) system with ovs 2.5 and mininet 2.2.1
Jenkins Label
dynamic_java
Minion Template name
centos7-java
Vagrant Definition
releng/builder/vagrant/basic-java-node
Spinup Script
releng/builder/jenkins-scripts/controller.sh
Jenkins Labels
ubuntu1604-mininet-ovs-26-2c-2g
Minion Template names
ubuntu1604-mininet-ovs-26-2c-2g
Packer Template
releng/builder/packer/templates/mininet-ovs-2.6.json
Playbook
releng/builder/packer/provision//mininet-ovs-2.6.yaml
- See dynamic_controller as it is currently the same image. + Ubuntu 16.04 (Xenial) system with ovs 2.6 and mininet 2.2.1
Jenkins Label
dynamic_java_8g
Minion Template name
centos7-java-8g
Vagrant Definition
releng/builder/vagrant/basic-java-node
Spinup Script
releng/builder/jenkins-scripts/controller.sh
Jenkins Labels
ubuntu1604-mininet-ovs-28-2c-2g
Minion Template names
ubuntu1604-mininet-ovs-28-2c-2g
Packer Template
releng/builder/packer/templates/mininet-ovs-2.8.json
Playbook
releng/builder/packer/provision//mininet-ovs-2.8.yaml
- See dynamic_controller as it is currently the same image but with 8G of RAM. + Ubuntu 16.04 (Xenial) system with ovs 2.8 and mininet 2.2.1
Jenkins Label
dynamic_devstack
Minion Template name
centos7-devstack
Vagrant Definition
releng/builder/vagrant/ovsdb-devstack
Spinup Script
releng/builder/jenkins-scripts/devstack.sh
Jenkins Labels
centos7-devstack-2c-4g
Minion Template names
centos7-devstack-2c-4g
Packer Template
releng/builder/packer/templates/devstack.json
Playbook
releng/builder/packer/provision/devstack.yaml
- A CentOS 7 system purpose built for doing OpenStack testing using + CentOS 7 system purpose built for doing OpenStack testing using DevStack. This minion is primarily targeted at the needs of the OVSDB project. It has OpenJDK 1.7 (aka Java7) and OpenJDK 1.8 (Java8) and other basic DevStack related bits installed. @@ -284,14 +343,14 @@ Pool: ODLRPC
Jenkins Label
dynamic_docker
Minion Template name
centos7-docker
Vagrant Definition
releng/builder/vagrant/ovsdb-docker
Spinup Script
releng/builder/jenkins-scripts/docker.sh
Jenkins Labels
centos7-docker-2c-4g
Minion Template names
centos7-docker-2c-4g
Packer Template
releng/builder/packer/templates/docker.json
Playbook
releng/builder/packer/common-packer/provision/docker.yaml
- A CentOS 7 system that is configured with OpenJDK 1.7 (aka Java7), + CentOS 7 system configured with OpenJDK 1.7 (aka Java7), OpenJDK 1.8 (Java8) and Docker. This system was originally custom built for the test needs of the OVSDB project but other projects have expressed interest in using it. @@ -299,18 +358,30 @@ Pool: ODLRPC
Jenkins Label
gbp_trusty
Minion Template name
gbp_trusty
Vagrant Definition
releng/builder/vagrant/gbp-ubuntu-docker-ovs-node
Spinup Script
releng/builder/jenkins-scripts/ubuntu-docker-ovs.sh
Jenkins Labels
ubuntu1604-gbp-2c-2g
Minion Template names
ubuntu1604-gbp-2c-2g
Packer Template
releng/builder/packer/templates/gbp.json
Spinup Script
releng/builder/jenkins-scripts/gpb.sh
- A basic Ubuntu node with latest OVS and docker installed. Used by Group Based Policy. + Ubuntu 16.04 (Xenial) node with latest OVS and docker installed. Used by Group Based Policy.
+Pool: ODLVEX - HOT (Heat Orchestration Templates) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +HOT integration enables to spin up integration labs servers for CSIT jobs +using heat, rathar than using jclouds (deprecated). Image names are updated +on the project specific job templates using the variable +`{odl,docker,openstack,tools}_system_image` followed by image name in the +format ` -