Solutions Delivery Platform

Configuration File Aggregation

When using the Jenkins Templating Engine, pipeline configuration files provided by Governance Tiers are inherited, and changes to the pipeline configuration are governed by a series of rules. These rules and the process by which Pipeline Configurations are aggregated is called Conditional Inheritance.

Configuration Hierarchy

The configuration hierarchy is determined by where the job is located on the Jenkins instance. Through this mechanism, arbitrarily complex configuration hierarchies can be created based upon how jobs are laid out on the Jenkins instance.

Let’s take a look at an example:

config hierarchy

Each time Job B is run, if present, the Pipeline Configurations from the Global Governance Tier, Folder 1, and the job itself will be aggregated in that order.

  • You can provide a Pipeline Configuration that applies to every pipeline on the Jenkins instance via Manage Jenkins > Configure System > Jenkins Templating Engine as part of the Global Governance Tier.

  • Pipeline Configurations can also be provided on every Folder on the Jenkins instance as part of a Governance Tier.

Limiting Customizations

The first configuration file found in the hierarchy may always define whatever fields it likes.

Subsequent configuration files will be limited in which already configured blocks can be customized.

Pipeline Configurations are free to add new blocks to the root of the pipeline configuration.

Merging

When configuring Pipeline Configurations, you can control which blocks subsequent configurations will be able to customize.

If subsequent Pipeline Configurations are permitted to add configuration to a block, but not override pre-existing values, then merge = true should be added to the block.

someBlock{
    merge = true
    // subsequent Pipeline Configurations can not change the value of someField
    someField = true

    // subsequent Pipeline Configurations may add additional fields
}

Overriding

If subsequent Pipeline Configurations are permitted to override a block’s configurations, then override = true should be added to the block.

someBlock{
    override = true
    // subsequent Pipeline Configurations can change the value of someField, or remove it completely by not declaring it.
    someField = true

    // subsequent Pipeline Configurations may add additional fields
}