Overriding Modules in MPL

[amenaafreen]

@sparshev How can we override few options in MPL, let's say in the build stage (Build module) we have the command ./gradlew clean build it won't be always clean build for gradle right? If we want to give the flexibility to the users like in the Build stage or test stage they can sometimes run their own commands. Also they can specify the system parameters during the builds, like the environment profiles, etc.

There's a snippet which I found

@Library('mpl@release') _

// Use default master pipeline
MPLPipeline {
  // Pipeline configuration override here
  // Example: (check available options in the pipeline definition)
  agent_label = 'LS'                     // Set agent label
  modules.Build.tool_version = 'Maven 2' // Change tool for build stage
  modules.Test = null                    // Disable Test stage
}

Here we are overriding the tool version right Similarly to override the shell commands Please let me know, ANy help is appreciated

[sparshev]

Hi @amenaafreen , The thing I could recommend - is to prepare a different modules for different purposes. Don't try to put everything in one module. But if you still need to add some flexibility for users - you can use params or env in the pipeline or pipeline configuration closure/map. So just like:

MPLPipeline {
  // Pipeline configuration override here
  // Example: (check available options in the pipeline definition)
  agent_label = 'LS'                     // Set agent label
  modules.Build.tool_version = "Maven ${params.MAVEN_VERSION}" // Change tool for build stage
  if( env.USE_TEST != "true" )
    modules.Test = null                     // Disable Test stage
}

Like that. So just read through the jenkins pipeline guide - the MPL is just a portion of groovy code on top of jenkins & pipeline. So anything you can image with pipelines or jenkins groovy - you can implement with MPL.

[sparshev]

@amenaafreen , probably you missed the point of my response. Let me try to explain again:

1. First of all - to provide flexibility for the user (who running the pipeline) - you need to setup the job parameters (please check in the google - "jenkins parametrized builds")
2. When you set the parameters - you can use the params global variable (check the pipeline global variables) - this params object will contain names of the specified job parameters and the values. Like: params.PARAM_NAME.
3. Now you can set the pipeline configuration with the params values:

   MPLPipeline {
       modules.Build.passed_param = params.PARAM_NAME
   }

4. Now, when the pipeline config contains required parameters - the configs will be passed to your module (depends on the module) and you will be able to use them in the command like: sh "./gradlew ${CFG.passed_param ?: 'clean build'}" - so the sh will get passed_param or, if it's not set - "clean build" as parameters to gradlew command.

For debugging - you can use a regular pipeline echo command to print the CFG values, or inject some println's in the MPL steps to figure out what's happening.

P.s. Please make sure you will check the value of CFG.passed_param in the module - because shell injection is a serious threat.

[sparshev]

@amenaafreen

Unfortunately your question is not related to MPL, but you can contact GridDynamics and get any help with your CICD or automation issues, we will be glad to help your company with any issues: https://www.griddynamics.com/

See you soon :)

[sparshev]

@amenaafreen MPL is not about logic you trying to implement, it's about managing the logic as modules. If you asking about "how to do" - it's not about MPL itself, it's about pipelines.

Please, check the examples, check the wiki, check the readme, carefully read about the jenkins pipeline engine and steps, shared libraries, try to debug the logic you have.

I can't prepare or debug the pipeline logic for you - I can only provide tools to help you with that. Hopefully, that will help you to find your answer.