DEV/Setting up JJB

From fd.io
Jump to: navigation, search

Introduction

fd.io uses Jenkins in conjunction with gerrit to run various different types of jobs:

  1. Verify jobs whenever a new job is submitted to gerrit.
  2. Merge jobs which run whenever a new patch is merged.
  3. Integration jobs which run whenever a project within fd.io you depend on merges a patch.

These jobs are defined per-project.

ci-management

The definition of the Jenkins Jobs is kept in Jenkins Job Builder format in the ci-management repo (soon to be a project).

Checking out ci-managment

git clone ssh://hagbard@gerrit.fd.io:29418/ci-management.git

Structure of ci-management

The crucial subdirectories for most projects in ci-management are:

  1. jjb/ - subdirectory defining project Jenkins Jobs in JJB format
  2. vagrant/ - subdirectory defining how Jenkins Slave snapshots are built

jjb/

For each project there needs to be a jjb/${reponame}/ subdirectory. Within that subdirectory there is usually one or more .yaml files, traditionally named ${reponame}.yaml, defining JJB jobs, and some scripts that are run by those jobs, generally named include-raw-${reponame}-${functional part}.sh.

Generally speaking, a patch to a projects jjb/ directory need to either originate with a committer for that project, or be +1ed by a committer for that project before they are generally considered for merge.

Example:

oberon:ci-management hagbard$ find jjb/nsh_sfc/
jjb/nsh_sfc/
jjb/nsh_sfc//include-raw-nsh_sfc-build.sh
jjb/nsh_sfc//nsh_sfc.yaml

In this example, the project repo name is nsh_sfc, and so all of its stuff lives under jjb/nsh_sfc/

jjb/nsh_sfc/nsh_sfc.yaml defines all the Jenkins Jobs for nsh_sfc.

jjb/nsh_sfc/include-raw-nsh_sfc-build.sh is a 'build' script that is referenced in nsh_sfc.yaml.

When changes are made to the JJB jobs, Jenkins automatically updates upon the completion of the merge job for that change.

vagrant/

vagrant/ provides the definitions used for creating snapshots used to spin up Jenkins Slaves.

oberon:ci-management hagbard$ find vagrant/
vagrant/
vagrant//basebuild
vagrant//basebuild/bootstrap.sh
vagrant//basebuild/README.txt
vagrant//basebuild/Vagrantfile
vagrant//lib
vagrant//lib/bootstrap-functions.sh
vagrant//lib/respin-functions.sh
vagrant//lib/system_reseal.sh

Currently we have only one subdir for builds, vagrant/basebuild, it contains a Vagrantfile, boostrap.sh, and README.txt.

Please note, in spite of being named 'vagrant' it doesn't follow the vagrant life cycle.Instead, the Vagrantfile is used to hint at the size for VMs, and the bootstrap.sh is used to 'provision' the VMs. The resulting VM image is then 'snapshotted' in a running state so it can be spun up quickly and easily.

If you need to change an image (say to add additional packages that need installation), you would change bootstrap.sh. Please note however, that there is a manual step which must be performed post merge by LF sysadmin staff, so the change does not happen automatically upon merge (ie, there will be some latency).