Skip to content

Instantly share code, notes, and snippets.

@steven-terrana

steven-terrana/example.md

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.
Download ZIP
Raw
example.md

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
@steven-terrana
Copy link
Author

steven-terrana commented Jan 31, 2022 •
edited
Loading

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