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
Thanks @cs3768 - You're finding all the bugs! :)
I've captured them in #253 and #254 and i'll patch them as soon as i'm able.
what's happening here is a collision with the fields on the actual ApplicationEnvironment class
basically... the application environment shouldn't be storing a
name
property because it's overriding thename
configuration you're providing.So.. in the interim until we can get that patched.. a valid work around would be to just try another name like
environment_name
.Appreciate your patience / help finding these issues!