Defaults are lost in case you use them with closure.

[ipleten]

Hello,
I'm trying to understand the purpose of 'defaults' in MplConfig, seems they are being overridden if I use closure in JenkinsFile:

MPLPipeline {
modules = [
     "schema": [:]
}

in MPLPipeline I call MPLPIpelineConfig as:

def MPL = MPLPipelineConfig(body, [
           modules [
             "schema": [some-aegs: "test"]
           ]
  ])

Expecting that eventually in MPLModule I'll get merged values of closures body from Jenkinsfile and defaults from MPLCPipelineConfig. But modules from Jenkinsfile always wins and no merging happens due to call body(), so modules just copied from Jenkinsfile. Meanwhile if I use Map in JenkinsFile it merged with defaults

Was it done intentionally and I'm missing something and/or MPLPipelineConfig supposed to be changed to meet my needs or it's just a bug? :)

[sparshev]

Hi @ipleten , as far I get it - you trying to replace modules with the new value - so there is no issue the previous default value was lost. The defaults just gave you defaults - for example if you will check what's inside modules during the closure execution - you will see the default value. In case you want to save it - you need to process it via the closure logic. Or you can use map - and it will try to merge it.

[ipleten]

Probably we've been misusing MPL form the beginning,
We have a lot of projects with Jenkinsfile like:

MPLPipeline {
modules = [
     "stage0": [:],
      "stage1": [:],
      "stage2": [PROJECT_SPECIFIC_VALUE:"value"],
}

Obviously, we have modules named: "stageX", under the hood MPLPipeline is a declarative pipeline with some mix of scripts.

We have a few types of pipelines for different types(5-6) of services . Also we have different modules which have a really small differences like: working_dir, mvn agruments and so on.

Some modules already used by all pipelines and some of them have something passed to them like stage0: [WORKDIR: "value"] and some of them not and use defaults hardcode in module. So we created copy of modules with different defaults 🤦 .
Currently all default values are hardcoded to modules body:

//stage0.groovy
WORK_DIR = CFG.WORKDIR ?: ['default_workdir']
//OTHER VARs HERE....
WORK_DIR.each {....VARs,VAR2s,....}

I want to move these default values from modules to MPLpipelineConfig level, so each type of pipeline would have it's own default in pipeline but not in module, therefore I'd be able to reuse modules across different pipelines with their own default values.
We can do that via Jenkinsfile in each repo but there are a lot of teams and projects and it would take a lot of time updating that.
All Jenkinsfiles use closure instead map. And unlikely it can be changed :(
So my intention is to get something like:

If module in Jenkinsfile has empty map like stage0: [:] it should take defaults from MPLPipelineConfig, which is common for most projects: stage0: [WD: "/home", MVN: "-pl '!integrations'"].

If there is something passed to stage0: [WD: "/var/lib/"] it should merge to default and effectively modules config would be: stage0: [WD: "/var/lib", MVN: "-pl '!integrations'"]

I don't see how I can achieve this without changing code of MPLPipelineConfig.

P.S. Want to thank you for this project as it helped as a lot with managing all these pipelines in centralized way.

[ipleten]

I did something like
#90

[sparshev]

I think the best way to get the example is to check the README.md#standard-pipeline-usage - it shows how to override the specific values and reuse the defaults. The defaults was prepared in order to provide some defaults to the Jenkinsfile userspace pipeline closure logic, and overrides is here to enforce some specific values for your pipelines.

But anyway, the way you want the MPL work will break the original interface, and I see no way to have both behaviors at the same time (probably boolean param will be a way - but it's an ugly one). So I'd rather suggest to have a fork of MPL for your organization with the patch you want as stated here: https://www.jenkins.io/blog/2019/01/08/mpl-modular-pipeline-library/#the-benefits-of-nested-libraries (Fig. 5).