Autowired Variables¶
The JTE framework often makes use of autowired variables to share both configuration data and contextual information.
This page outlines the various autowired variables, their scope, and what data they provide.
Overview¶
Variable | Description | Scope |
---|---|---|
pipelineConfig |
Represents the aggregated Pipeline Configuration | Accessible everywhere |
jte |
The Primitive Namespace object | Accessible everywhere |
config |
Represents a library's configuration provided by the aggregated Pipeline Configuration | Within Library Steps |
stepContext |
Enables step introspection. Especially helpful when using Step Aliasing | Within Library Steps |
hookContext |
Represents contextual information for Lifecycle Hooks | Within Library Steps |
Autowired Global Variables¶
pipelineConfig
¶
The pipelineConfig
is accessible from everywhere and allows access to the aggregated Pipeline Configuration as a Map.
Example Usage of pipelineConfig
An example of accessing the Pipeline Configuration via pipelineConfig
:
keywords{
foo = "bar"
}
random_field = 11
println pipelineConfig.keywords.foo
println pipelineConfig.random_field
jte
¶
The jte
variable represents the Primitive Namespace.
All loaded Pipeline Primitives for a Run can be accessed via the jte
variable
This is different from the pipelineConfig
variable. The pipelineConfig
variable gives a Map representation of the aggregated Pipeline Configuration whereas the jte
variable allows access to the actual Pipeline Primitive objects.
Example Usage of jte
Assume there's a gradle
and an npm
library that both contribute a build()
step.
By default, loading would result in the pipeline failing. However, you can perform Step Overloading by setting jte.permissive_initialization
to True
.
The jte
would be used in this scenario to invoke the build()
step from the gradle
and npm
libraries.
jte{
permissive_initialization = true
}
libraries{
gradle
npm
}
// invoke the gradle build step
jte.libraries.gradle.build()
// invoke the npm build step
jte.libraries.npm.build()
jte
block vs jte
variable
You may have noticed in the example above that a jte{}
block is used in the Pipeline Configuration and a jte
variable is used in the Pipeline Template.
These are different things.
The jte{}
block refers to framework-level feature flags as explained on the Pipeline Configuration schema page.
The jte
variable refers to the Pipeline Primitive Namespace variable.
steps
¶
The steps
variable doesn't technically come from JTE.
It's a feature of all Jenkins Pipelines.
The steps
variable allows direct access to invoke Jenkins Pipeline DSL Steps.
This variable is most commonly used when invoking Jenkins Pipeline DSL Steps from a Library Class or when Overloading Steps.
Autowired Library Step Variables¶
The following variables are only accessible within Library Steps.
config
¶
The config
variable represents the library configuration for the library that contributed the step as a Map.
Example Usage of config
Assume there's a gradle
library that contributes a build()
step.
libraries{
gradle{
version = "6.3"
}
}
void call(){
String gradleVersion = config.version
}
hookContext
¶
The hookContext
variable provides information about the current step to Lifecycle Hooks.
Property | Type | Description |
---|---|---|
library |
String |
The library that contributed the step that triggered the Lifecycle Hook. Is null when the Lifecycle Hook wasn't triggered by a step. |
step |
String |
The name of the Library Step that triggered the Lifecycle Hook. Is null when the Lifecycle Hook wasn't triggered by a step. |
methodName |
String |
The name of the method within the step that was invoked to trigger the Lifecycle Hook. Is null when the Lifecycle Hook wasn't triggered by a step. |
exceptionThrown |
Boolean |
When the hook is triggered by a step, this refers to if the step triggering step threw an exception. When the hook is triggered by template completion, refers to if there is an uncaught exception that will fail the pipeline. |
Example hookContext
usage
The following example shows how to use the hookContext
variable so that a Lifecycle Hook only triggers after the build()
step from the gradle
library.
@AfterStep({ hookContext.library == "gradle" && hookContext.step == "build" })
void call(){
println "running after the ${hookContext.library}'s ${hookContext.step} step"
}
stageContext
¶
The stageContext
variable provides information about the current Stage.
Property | Type | Description |
---|---|---|
name |
String |
The name of the current Stage being executed. null if step isn't being executed as part of a Stage. |
args |
Map |
The named parameters provided to the Stage. An empty Map if no parameters provided. |
Example usage of stageContext
The following example shows how to modify step behavior based upon Stage context.
libraries{
npm // contributes unit_test()
sonarqube // contributes static_code_analysis()
}
stages{
ci{
unit_test
static_code_analysis
}
}
void call(){
if(stageContext.name == "ci"){
println "running as part of the ci Stage"
}
}
stepContext
¶
The stepContext
allows step introspection, such as querying the name of the library providing the step or the current name of the step.
Property | Type | Description |
---|---|---|
library |
String |
The name of the library that contributed the step |
name |
String |
The current name of the step. May differ from the basename of the step's groovy file if using Step Aliasing |
isAlias |
Boolean |
Is true when stepContext.name refers to an alias |
Example usage of stepContext
@StepAlias(["build", "unit_test"])
void call(){
println "currently running as ${stepContext.name}"
}
build() // prints "currently running as build"
unit_test() // prints "currently running as unit_test"