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:
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.
|
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
}