I’m not sure if the video you saw online was this one, but at the CDF Online Meetup I gave a no-slides all live-demo presentation introducing JTE that gets into this a bit.
The page of docs you’d be looking for is Parameterizing Libraries.
Basically, the library configuration from the pipeline configuration is made available to steps via a config variable.
pipeline_config.groovy
libraries{
maven{
message = “hello world”
}
}
maven library: maven/steps/build.groovy
void call(){
// config variable is injected into
// each library step and has the full
// library configuration
println “hello from the maven library: {config.message}“
}
pipeline template:
// templates get run as Jenkinsfiles
// just with some extra stuff added in
node{
sh "echo hi"
}
build() // <-- from the maven library
Generally, it's recommended that library configuration be passed via the config variable and pipeline configuration file over parameterizing the step itself.
The reason is because that with pipeline templates being reusable across teams using different tools.. the build() step might be coming from different libraries.
Parameterizing the step would require that every library that contribute a build step accept the same parameters.
The one exception to that would be when using Application Environments.
for example:
pipeline config:
libraries{
ansible // contributes a deploy_to
}
application_environments{
dev{
ip = "1.1.1.1"
}
prod{
ip = "2.2.2.2"
}
}
library step: ansible/steps/deploy_to.groovy
/*
accepts an application environment variable to capture environmental context
this is okay because every deploy_to step would also take an app_env parameter
*/
void call(app_env){
println "deploying to {app_env.short_name}: {app_env.ip}"
}
pipeline template:
deploy_to dev // deploy_to from ansible, dev variable from application_environments
deploy_to prod // prod variable from application environments
