[JIRA] (JENKINS-61147) load build parameters during repository scan

load build parameters during repository scan

Issue Type:	New Feature
Assignee:	Unassigned
Components:	pipeline
Created:	2020-02-19 13:48
Environment:	jenkins 2.220, running in kubernetes, using declarative pipelines & multi-branch pipelines
Labels:	pipeline user-experience
Priority:	Minor
Reporter:	Roland Eschenburg

It's a massive bugbear for me and I'm sure many others.. having to build a pipeline once before you can 'Build with Parameters'.

It could be as simple as checking out just the jenkinsfile(s) during the repository scan and load the parameters before the first build (obviously as an option to enable it as it would slow down the repository scan).

Alternatively, give us a 'load/refresh parameters' button that starts the pipeline but only until it has got the parameters and then stops by itself before doing any build steps.

This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)

brandon@fryslie.com (JIRA)

unread,

Feb 21, 2020, 4:52:02 PM2/21/20

to jenkinsc...@googlegroups.com

Brandon Fryslie commented on

https://jenkinsci.github.io/job-dsl-plugin/

This is not necessary if you are using the Job DSL plugin (which you should be regardless). Instead of defining the parameters in your Jenkinsfile, put them in the .groovy file where your Job DSL is defined. Then the parameters are available on the initial run of the job.

mdealer@gmail.com (JIRA)

unread,

Mar 2, 2020, 3:16:03 AM3/2/20

to jenkinsc...@googlegroups.com

Edgars Batna commented on

I don't know what Brandon means - the link does not provide any information on why would we need Job DSL when we're already using Multibranch Pipeline. As I see it, Job DSL has nothing to do with this issue, plus it has its own assumptions and use cases which do not fit to our scenarios.

This is a missing important feature.

This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)

mdealer@gmail.com (JIRA)

unread,

Mar 2, 2020, 3:20:03 AM3/2/20

to jenkinsc...@googlegroups.com

Edgars Batna edited a comment on

I don't know what Brandon means - the link does not provide any information on why would we need Job DSL when we're already using Multibranch Pipeline. As I see it, Job DSL has nothing to do with this issue, plus it has its own assumptions and use cases which do not fit to our scenarios.

This is a missing important feature. I see it as a bug, because it's no longer possible to use expressions for default values.

mdealer@gmail.com (JIRA)

unread,

Mar 2, 2020, 3:21:02 AM3/2/20

to jenkinsc...@googlegroups.com

Edgars Batna edited a comment on

I don't know what Brandon means - the link does not provide any information on why would we need Job DSL when we're already using Multibranch Pipeline. As I see it, Job DSL has nothing to do with this issue, plus it has its own assumptions and use cases which do not fit to our scenarios.

This is a missing important feature . and I can even see it as a bug, because it makes using expressions for default values impossible.

mdealer@gmail.com (JIRA)

unread,

Mar 2, 2020, 3:21:02 AM3/2/20

to jenkinsc...@googlegroups.com

Edgars Batna edited a comment on

I don't know what Brandon means - the link does not provide any information on why would we need Job DSL when we're already using Multibranch Pipeline. As I see it, Job DSL has nothing to do with this issue, plus it has its own assumptions and use cases which do not fit to our scenarios.

This is a missing important feature. I see it as a bug, because it 's no longer possible to use makes using expressions for default values impossible .

roland.eschenburg@hotmail.co.uk (JIRA)

unread,

Mar 2, 2020, 4:52:03 AM3/2/20

to jenkinsc...@googlegroups.com

Roland Eschenburg commented on

Edgars Batna - Agreed.
Whilst I see Brandon's point that using the Job DSL plugin would be a potential 'workaround' - I disagree with the 'which you should be regardless' assessment. What plugins someone can/can't use or wants to/doesn't want to use is up to the individual.

Using Jenkinsfiles but creating build jobs manually is still a very common pattern and in those scenarios this feature would be incredibly useful.

brandon@fryslie.com (JIRA)

unread,

Mar 2, 2020, 7:23:03 PM3/2/20

to jenkinsc...@googlegroups.com

Brandon Fryslie edited a comment on

This is not necessary if you are using the Job DSL plugin - (which you should be regardless) - . Instead of defining the parameters in your Jenkinsfile, put them in the .groovy file where your Job DSL is defined. Then the parameters are available on the initial run of the job.

[https://jenkinsci.github.io/job-dsl-plugin/]

EDIT: Apologies, I wasn't implying that this isn't a valid feature request. However, using the Job DSL allows you to achieve what you are asking, and it makes your life easier in the long run as well.