tree: 5cac0a67e1ba6d51d6e5fd39752ac4a002c35762 [path history] [tgz]
  1. .coafile
  2. .editorconfig
  3. .gitignore
  4. .gitmodules
  5. .gitreview
  6. Makefile
  7. README.md
  8. jenkins-scripts/
  9. jenkins.ini.example
  10. jjb/
  11. packer/
  12. tox.ini
  13. yamllint.conf
README.md

ci-management for CORD

This repo holds configuration for the Jenkins testing infrastructure used by CORD.

The best way to work with this repo is to check it out with repo, per these instructions: Downloading testing and QA repositories

NOTE: This repo uses git submodules. If you have trouble with the tests or other tasks, please run: git submodule init && git submodule update to obtain these submodules, as repo won't do this automatically for you.

Jenkins Job Builder (JJB) Documentation

Official JJB Docs

LF Best practices for JJB

Adding tests to a new git repo

When adding a new git repo that needs tests:

  1. Create a new file in jjb/verify named <reponame>.yaml

  2. Create a project using the name of the repo, and a job-group section with a list of jobs-template ids to invoke.

  3. Optional: If you have more than one job that applies to the repo, add a dependency-jobs variable to each item the job-group jobs list to control the order of jobs to invoke. Note that this is a string with the name of the jobs as created in Jenkins, not the job-template id.

Making a new job-template

To create jobs that are usable by multiple repos, you want to create a job-template that can be used by multiple jobs.

Most job-templates are kept in jjb/*.yaml. See lint.yaml or api-test.yaml for examples.

Every job-template must have at least a name (which creates the name of the job in Jenkins) and an id item (referred to in the job-group), as well as several modules that invoke Jenkins functionality, or macros (see below, and in the docs) that customize or provide defaults for those modules.

Setting default variable values

Default values can be found in jjb/defaults.yaml. These can be used in projects, jobs, job-templates.

NOTE: Defaults don't work with macros - all parameters must be passed to every macro invocation.

Creating macros

If you need to customize how a Jenkins module is run, consider creating a reusable macro. These are generally put in jjb/cord-macros.yaml, and have names matching cord-infra-*.

See also global-jjb/jjb/lf-macros.yaml for more macros to use (these have name matching lf-infra-*).

There are a few useful macros defined in jjb/cord-macros.yml

  • cord-infra-properties - sets build discarder settings
  • cord-infra-gerrit-repo-scm - checks out the entire source tree with the repo tool
  • cord-infra-gerrit-repo-patch - checks out a patch to a git repo within a checked out repo source tree (WIP, doesn't work yet)
  • cord-infra-gerrit-trigger-patchset - triggers build on gerrit new patchset, draft publishing, comments, etc.
  • cord-infra-gerrit-trigger-merge - triggers build on gerrit merge

Testing job definitions

JJB job definitions can be tested by running:

make test

Which will create a python virtualenv, install jenkins-job-builder in it, then try building all the job files, which are put in job-configs and can be inspected.

The output of this is somewhat difficult to decipher, sometimes requiring you to go through the python backtrace to figure out where the error occurred in the jenkins-job-builder source code.

AMI Images and Cloud instances

If you make changes which create a new packer image, you have to manually set the instance AMI ID on jenkins in Global Config > Cloud > Amazon EC2.

Creating new EC2 instance types

If you create a new cloud instance type, make sure to set both the Security group names and Subnet ID for VPC or it will fail to instantiate.

Links to other projects using LF JJB