Skip to content

Instantly share code, notes, and snippets.

@steven-terrana
Last active January 31, 2022 16:58
Show Gist options
  • Save steven-terrana/4d3087628ad3544b76d03d343840bfab to your computer and use it in GitHub Desktop.
Save steven-terrana/4d3087628ad3544b76d03d343840bfab to your computer and use it in GitHub Desktop.

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
@cs3768
Copy link

cs3768 commented Jan 30, 2022

Steven -- This was very helpful. I got the maven library parameter to dereference in my library.

Still having an issue with application_properties, though. Here's the relevant snip from my pipeline_config-groovy file:

// Environments
application_environments {
dev{
name="Development-Build"
}
}

I have a lib that calls environment(dev) from my Jenkinsfile as shown:
envrionment("dev")

I'm doing this in my environment.groovy file:

void call(app_env){
println "Build: {app_env.name}";
}

But: my console output shows this:

[JTE][Step - environment/environment.call(ApplicationEnvironment)]
[Pipeline] echo (hide)
Build: dev

appenv seems to be getting across, but the "name" definition is not derefernced.

Any ideas?

Thanks,
--ccs

@steven-terrana
Copy link
Author

steven-terrana commented Jan 31, 2022

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 the name 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!

@cs3768
Copy link

cs3768 commented Jan 31, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment