Skip to content

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:

pipeline_config.groovy
keywords{
  foo = "bar"
}
random_field = 11
Jenkinsfile
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.

pipeline_config.groovy
jte{
  permissive_initialization = true
}
libraries{
  gradle
  npm
}
Jenkinsfile
// 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.

pipeline_config.groovy
libraries{
  gradle{
    version = "6.3"
  }
}
build.groovy
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.

pipeline_config.groovy
libraries{
  npm // contributes unit_test()
  sonarqube // contributes static_code_analysis()
}
stages{
  ci{
    unit_test
    static_code_analysis
  }
}
unit_test.groovy
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

generic.groovy
@StepAlias(["build", "unit_test"])
void call(){
  println "currently running as ${stepContext.name}"
}
Jenkinsfile
build() // prints "currently running as build"
unit_test() // prints "currently running as unit_test"
Back to top