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 fields or blocks to the root of the pipeline configuration. |
Merging
When configuring Pipeline Configurations, you can control which blocks subsequent configurations will be able to extend.
If subsequent Pipeline Configurations are permitted to add configuration to a block, but not override pre-existing values, then @merge should be added to the block.
@merge someBlock{ (1)
someField = true (2)
// <-- subsequent Pipeline Configurations may add additional fields
}| 1 | Subsequent pipeline configurations will be able to add additional fields to someBlock |
| 2 | Subsequent pipeline configurations can not modify the value of someField |
Overriding
If subsequent Pipeline Configurations are permitted to override a block’s configurations, then @override should be added to the block.
@override someBlock{ (1)
someField = true (2)
// <-- subsequent Pipeline Configurations may add additional fields
}| 1 | By setting @override on the block level, subsequent configurations of the block will be substituted for what’s currently set. |
| 2 | Subsequent pipeline configurations can override the value of someField by setting the value to something new. Subsequent configurations could also unset the value of someField by not declaring it all. |
Field-Level Governance
If there is a configuration block that should enforce certain default values to be inherited but allow subsequent pipeline configurations to override other fields, a combination of @merge at the block-level and @override at the field-level can be used.
@merge someBlock{ (1)
parameterA = 11 (2)
@override parameterB = 12 (3)
}| 1 | Subsequent configurations will be able to add additional configurations to someBlock but not override existing configurations unless it is explicitely allowed. |
| 2 | The existing value of parameterA will be inherited and can not be overridden by subsequent configurations |
| 3 | Subsequent configurations can override the value of parameterB because it is annotated with @override |