We are now using the Jenkins multi-branch pipeline to build the OpenAM project.

Having that pipeline may change your habits but it should be for the best.

Why define the pipeline as code?

As developing new functionality can impact the build process, having the build scripts close to the OpenAM codebase is beneficial.

Having a pipeline is also the first step to continuous delivery where every commit could go into production. This means each commit should be treated as a potential release and built the same way.

One advantage of having the same pipeline for our daily work and the release is that we are quite confident that all the stages work. If we run them many time a day, there are fewer chances to spend many weeks at the end of the release cycle to fix gloomy stages. The key to making painful tasks less painful is to do them more often.

Pipeline Execution

The mandatory stages are the stages run by default in the following cases :

On updating the PR, any currently running pipelines will be terminated with the exception of manually triggered executions (via the button). This is to account for the 'rebase, push, squash, push' workflow which would otherwise trigger multiple executions.

Mandatory stages vs Optional stages

All those stages must pass in order to merge your PR ( see welcome your new Reviewer )

The mandatory stages are :

The optional stages are :


Because we understand that you may have corner cases we have introduced a bit of flexibility in the way Jenkins executes the stages of the pipeline.


How to control the stages executed in your PR

First, Add the following string to the bottom of your PR description “CI build configuration” ( It's case and formatting insensitive )

Here is the list of controls you can specify:

        only-stages=smoke-tests
groups=ciba 

N.B. : comma delimited lists (without spaces)

N.B. : optional-stages, skip-stages and only-stages support '*' as a value. If '*' is used as a value it will match every stage.

Note: Master and 6.5.x branch were updated - change how groups are handled. The only option for configuring groups is now `groups=<groups>` in the CI Build Configuration. The intersection of the provided groups with each stage will then be run. This means that running with `groups=oauth2` will run only the oauth2 grouped tests in the mandatory stages. You can also use expressions, for example `groups=or(oauth2, session)` or `groups=and(oauth2, not(oidc))`.


The previous set of commands are useful to tweak the pipeline and get the feeback you need.

The following set of command is useful when you are writing a stage or testing the pipeline :


Examples of custom build passed in the PR description are :

You already executed the pipeline with the mandatory stages and I want to know the state of the functional tests.











This will execute the build and the functional-tests stage


You want to run the functional-tests and the mandatory stages


This will run the build → smoke tests → security tests → amster tests → functional tests

How to test a change which involves modifying OpenAM and Temper

If you have an OpenAM pull request and a temper pull request you can start the OpenAM pipeline with your temper PR by adding temper-pr command to the “CI build configuration”. You must set the temper pr id as in this example :


Ci build configuration

temper-pr=1466


Where 1466 is the id of your temper PR. This id can be looked up in your PR overview url.

How to test a change which involves modifying OpenAM and Commons

If you have an OpenAM pull request and a Commons pull request you can start the OpenAM pipeline with your commons PR by adding commons-pr command to the “CI build configuration”. You must set the commons pr id as in this example :


Ci build configuration

commons-pr=1466


Where 1466 is the id of your commons PR. This id can be looked up in your PR overview url.

The version of commons used in the AM build will be automatically set to the version that is in the branch the PR is from.

Welcome your new Reviewer 

When a pull request is created a build is triggered automatically and the Jenkins user will join the PR soon after.

The Jenkins user will only approve your PR if all the mandatory stages pass.

A pull-request shouldn’t be merged if Jenkins didn’t approve your PR.

Note that if you skip mandatory stages, Jenkins will not approve your PR and will remove any previous approval unless you didn't push new files between your two builds.

Child pages