Skip to content

Build overview

Sam Gleske edited this page Jun 5, 2018 · 18 revisions

This document is a brief outline of the Jervis build overview. Travis CI also outlines a build overview.

Build lifecycle

This documentation outlines the execution order of a build. This general process happens no matter what language is being built.

Note: encrypted secrets are decrypted when a job is run.

  1. Clone the repository and cd to it.
  2. Decrypt encrypted files.
  3. Clean up any private keys used for decryption (i.e. removing RSA private keys from the master where decryption occurs, etc.).
  4. Matrix building toolchains (i.e. set up the environment for the build like what version of python or ruby, etc). This is the first time user configured code is executed from the .jervis.yml. Setting up the matrix exclusions happen here as well.
  5. Perform the build lifecycles in the following order. Any one of the following steps can be overridden by the .jervis.yml.
  6. before_install - commands that run before the install step. e.g. point rubygems at an internal gem caching proxy such as geminabox or Nexus.
  7. install - commands that run to assemble dependencies.
  8. before_script - commands that prepare your system for testing. e.g. populate a database.
  9. script - commands to run unit tests.

The following options are not implemented. See also issue https://github.com/samrocketman/jervis/issues/130

  • after_success or after_failure - Execute commands depending on the outcome of the build.
  • after_script - Always execute these commands after the build.

Define custom build lifecycle commands

Here is a sample .jervis.yml yaml file with all of the build lifecycles (non-matrix build) executing only a single command at each step. If you define the lifecycles in your .jervis.yml file then you will override the default set by the Supported Languages.

language: python
before_install: sudo apt-get install python-pip mariadb
install: pip install -r requirements.txt
before_script: sudo mysql < database.mysql
script: python setup.py test

Here is a sample .jervis.yml with some of the build lifecycles (non-matrix build) executing multiple commands.

language: python
before_install:
  - sudo apt-get install python-pip python-virtualenv mariadb
  - VIRTUALENV=$(mktemp -d)
  - virtualenv "${VIRTUALENV}"
  - source "${VIRTUALENV}"/bin/activate
install: pip install -r requirements.txt
before_script:
  - sudo mysql < database.sql

Specify branches to build

By default Jervis will generate Jenkins jobs for all branches that have a .travis.yml or .jervis.yml file. You can control and limit this behavior by specifying the branches key in your .jervis.yml.

Whitelist or blacklist branches

You can either whitelist or blacklist branches that you want to be built:

# blacklist
branches:
  except:
    - legacy
    - experimental

# whitelist
branches:
  only:
    - master
    - stable

If you specify both, except will be ignored. .jervis.yml needs to be present on all branches you want to be built. .jervis.yml will be interpreted in the context of that branch so if you specify a whitelist in your master branch it will not propagate to other branches.

Using regular expressions

Note: if using a regular expressions within an only (whitelist) filter on the default branch, then this will become a regex to apply filtering on all branches. Even if branches specify an except filter, the only filter from the default branch will override it. If the default branch is using an except filter or no branch filter, then a whitelist will be determined per branch. This is in context of Jervis generating a multibranch pipeline job.

You can use regular expressions to whitelist or blacklist branches:

branches:
  only:
    - master
    - /^deploy-.*$/

Any name surrounded with / in the list of branches is treated as a regular expression. The expression will use Pattern.compile to compile the regex string into a Groovy regular expression.

Encrypted secrets

To learn more about securing data in your repository for the build process please see Secure secrets in repositories.

Matrix builds

To learn more about matrix builds see Matrix job support.