Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can we have a top-level getter for cron similar to agent_label? #85

Closed
maxime-michel opened this issue Mar 12, 2021 · 5 comments
Closed
Labels
question Further information is requested

Comments

@maxime-michel
Copy link

In our setup, some pipelines require a custom cron:

triggers {
  cron('@weekly')
}

We already have a setup in which no cron is defined by default, and some project pipelines can override that. However, I would like to replicate this with MPL, because MPL brings a lot more flexibility than the templates we are currently working with.

Do I get this right that because that property is top-level such as agent_label, then a getter would be needed in MPLManager? What are you thoughts on adding it?

@sparshev
Copy link
Collaborator

Hi @maxime-michel , as far I get it - you worrying about the pipeline configuration? So the MPLPipeline is just an example - and for sure you can copy it and create your pipeline definition with the configuration you want. I'm quite sure you even can create a dynamic trigger definition (use cron or whatever trigger you want) by adding a custom step in vars definitions.

Please check the custom pipeline example here to get some references in mpl-nested/vars/NestedPipeline.groovy: https://github.com/griddynamics/mpl/wiki#examples

@maxime-michel
Copy link
Author

Hi @sparshev,

Thanks for your answer. I am already working with a nested MPL pipeline, which I defined here: https://github.com/magnolia-cms/test-mpl-nested-library/blob/master/vars/NestedPipeline.groovy

And while I can successfully configure MPL modules or individual stages (such as the Maven version used for the build shown in the example), my problem is that cron is a property that is outside of the scope of MPL modules:

pipeline {
    agent any
    triggers {
        cron('H */4 * * 1-5')
    }
    stages {
        stage('Example') {
            steps {
                echo 'Hello World'
            }
        }
    }
}

Using cron(MPL.cron) simply blows up with: hudson.remoting.ProxyException: groovy.lang.MissingPropertyException: No such property: cron for class: com.griddynamics.devops.mpl.MPLManager

Whereas it would work with MPL.agentLabel thanks to the following getter in MPLManager: https://github.com/griddynamics/mpl/blob/master/src/com/griddynamics/devops/mpl/MPLManager.groovy#L87

The only way to support my use case would be that getCron() gets defined in MPLManager, because I don't think I'm supposed to write my own MPLManager. Or am I wrong?

@sparshev
Copy link
Collaborator

So, I think what you need - is to just use the configuration, because you know - modifying of the core MPL for each small parameter is quite bad way to manage the configuration. The getAgentLabel() was introduced due to it's common nature for every pipeline (which uses labels).

For anything else I would recommend to use cron(MPL.config.cron) in your case - just access the config directly, it's marked as private but accessible in groovy. But overall I think it's possible to add getConfig() method to allow proper access via MPLConfig to the whole pipeline configuration. And it will work well just as usual MPL.config.'property.path'. So for now please use just MPL.config and I will think about it more and prepare the change to simplify our life)

@maxime-michel
Copy link
Author

Thank you! That's perfectly acceptable for me, I just didn't quite see how to pull this out. I'll close this issue since the API you have in mind has little to do with what's been described here, OK?

@sparshev
Copy link
Collaborator

Ok, created a new ticket to implement the discussed interface.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants