[JIRA] (JENKINS-41929) Offer "Build with Parameters" on first build when declarative Jenkinsfile found

[jglick@cloudbees.com (JIRA)]

Jesse Glick created an issue

Jenkins / JENKINS-41929 Offer "Build with Parameters" on first build when declarative Jenkinsfile found Issue Type: New Feature Assignee: Andrew Bayer Components: pipeline-model-definition-plugin Created: 2017/Feb/10 3:24 PM Priority: Major Reporter: Jesse Glick By default a branch project will automatically run the first build, with no parameters, so params will just pick up any default values. You have the option to suppress the automatic first build, but this does not give you any way to enter parameters for it (at least in the UI; perhaps possible via CLI/REST), since Jenkins does not know what the parameters are going to be until it starts running. But in the case of Declarative we could in principle inspect the Jenkinsfile when the branch project is created (via SCMFileSystem) and determine the parameter definitions by static parsing without actually running. More generally, if Declarative is in use and there are properties, we could set all the project properties when the branch project is created, even if the first build is run automatically. (Though I would suggest that the automatic first build should be automatically suppressed if there is a ParametersDefinitionProperty.) Add Comment

This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)

[dima_ben@ukr.net (JIRA)]

Dmitry Bondarenko commented on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found In JENKINS 2.107.2 (April 2018) there are some minor problems with parameters. In particular - parameters sometimes are not recognized from pipeline definitions. I need to start build couple of times as-is to make parameters recognized. Also when I added new a "choice" parameter to existing parameters it was not recognized at all. So, I have to add it in UI (separately from pipeline definitions). And pipeline definitions were not sync from UI parameters, so such parameter was defined in UI for pipeline but it was not added to pipeline script. Thus, "pipeline script" and "pipeline parameters" in UI editor can be very different. Also a bad thing - it does not provide a possibility to specify captions for choice-values! For example I would like to use INI-file format for such purposes, so like this - choise: ['R2010B=Release 2010.2\nR2015=Release 9.0\nR2016=Release 9.1\nR2017=Release 2017.1'] - such format will be much more useful for end-user. So, when calling a build script it should use choice value "R2017" and the "Release 2017.1" text is only to show in UI for user when choosing a parameter value for a build.

Add Comment

This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)

[kiruahxh@gmail.com (JIRA)]

Kiruahxh commented on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

@Mention Murad Korejo How about a special "Refresh Parameters" option for pipeline projects? It won't run the full job but "processes" the pipeline script by downloading latest from source and updates things in the job config such that new/changed params are reflected. I agree, a button or an option "Refresh parameters" would be ok for scripted pipelines. The job could have a refreshParameter variable in input, and its status should be discarded. Another possibility would be to split the Jenkinsfile in two : one file for job properties and parameters, and another for the execution script. Ex : Jenkinsproperties ans Jenkinsfile As a workaround, I put a "refresh parameter" option in my jobs.

Add Comment

[jtmorton@calpoly.edu (JIRA)]

John Morton commented on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

I would highly suggest implementing this feature. This makes using parameterized Declarative Pipelines a hassle for us and either has us using non-ideal workarounds. There should just be a button for all pipeline jobs that says "re-pull from SCM". This should pull the Jenkinsfile from SCM and changes it from a default unparameterized build to a parameterized build but does not actually run a "build".

Add Comment

[xdhmoore@gmail.com (JIRA)]

Daniel Moore commented on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

I am not familiar with the Jenkinsfile API, but as a workaround for declarative pipelines, would it work to create a decorator `param-pipeline` method and use it instead of the `pipeline` method? It could take the same arguments/script blocks/whatever as `pipeline` and look at the defined parameters and try to update the job accordingly. If the job already had the right parameter setup than it would just pass its arguments to the `pipeline` method. You would still have to run it twice, so not ideal.

Add Comment

[xdhmoore@gmail.com (JIRA)]

Daniel Moore edited a comment on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

I am not familiar with the Jenkinsfile API, but as a workaround for declarative pipelines, would it work to create a decorator ` * param-pipeline ` * method and use it instead of the ` * pipeline ` * method? It could take the same arguments/script blocks/whatever as `pipeline` and look at the defined parameters and try to update the job accordingly. If the job already had the right parameter setup than it would just pass its arguments to the `pipeline` method. You would still have to run it twice, so not ideal.

Add Comment

[xdhmoore@gmail.com (JIRA)]

Daniel Moore edited a comment on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

I am not familiar with the Jenkinsfile API, but as a workaround for declarative pipelines, would it work to create a decorator *param-pipeline* method and use it instead of the *pipeline* method? It could take the same arguments/script blocks/whatever as `  * pipeline ` * and look at the defined parameters and try to update the job accordingly. If the job already had the right parameter setup than it would just pass its arguments to the `  * pipeline ` * method. You would still have to run it twice, so not ideal.

Add Comment

[kiruahxh@gmail.com (JIRA)]

Kiruahxh commented on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

Also, when using the "properties" step, either to declare parameters or set other options, the job options are still editable. It is flexible but very confusing : my colleagues could edit the jobs parameters without knowing that they are taken from the Jenkinsfile, then run the job and loose their work.

Add Comment

[tom.ghyselinck@excentis.com (JIRA)]

Tom Ghyselinck commented on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

Hi all, More in general the parameters of the "previous" run are used. We have seen this when playing around with some kind of "dynamic value" for a parameter. We have a single (declarative) Pipeline which has a parameter to enable a DEBUG build. During the continuous CI builds, DEBUG mode is enabled, i.e. the `BUILD_DEBUG` parameter to false. On a nightly build, we set the `BUILD_DEBUG` parameter to false. pipeline { ... parameters { booleanParam( name: 'BUILD_DEBUG', defaultValue: need_debug_build(currentBuild) ) } ... } We now see that: the "nightly build" correctly sets the parameter to false and the "daily builds" correctly set it to true. but the parameter value is only applied in the next build ! For example: The "nightly build" still uses `DEBUG_BUILD=true` While the first "daily build" uses `DEBUG_BUILD=false` I.e. When creating a new branch this applies too: (FYI: We use the Multibranch pipeline plugin on subversion repositories) The first build has no "previous build"and thus "no parameters" Which exactly explains what is seen on the first build of a (declarative) pipeline. In my opinion the `parameters` must be defined and applied on the current build. I hope this information is of any use for you! We will look for a workaround for now, but it would be great to see this fixed. Thank you in advance for the effort! With best regards, Tom.

Add Comment

[jglick@cloudbees.com (JIRA)]

Jesse Glick commented on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

the pipeline will then fail as the parameters will not be set No, you just need to use ${params.NAME} rather than ${NAME}. The latter loads a variable defined when the build started. The former will pick up current parameter definitions at the time the expression is used, which may be after properties has (re-)defined the job’s parameters list. For builds triggered by a PR event, this is fine, as there are no parameters coming from the environment—you are getting defaults.

Add Comment

[aditya.sreekumar@gmail.com (JIRA)]

Adity Sreekumar commented on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

When was the ${params.Name} syntax introduced? It does not seem to detect that when I use it in the following context:     {{parameters{ string ( defaultValue: '1.0', description: 'Toolchain version', name : 'TOOLCHAIN') } steps{    checkout ($class: 'GitSCM', branches = [[name: '$\{params.TOOLCHAIN}']]]) }}}   If I use just TOOLCHAIN, it gices me the error reported earlier where it cannot find the environment variable.

Add Comment

[aditya.sreekumar@gmail.com (JIRA)]

Adity Sreekumar edited a comment on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

When was the _$\{params.Name}_ syntax introduced? It does not seem to detect that when I use it in the following context:

\ { \ {parameters\{    string (       defaultValue: '1.0',       description: 'Toolchain version',       name : 'TOOLCHAIN') } steps\{    checkout ($class: 'GitSCM', branches = [[name: '$\ \

{params.TOOLCHAIN}']]]) }}}   If I use just TOOLCHAIN, it gices gives me the error reported earlier where it cannot find the environment variable.

Add Comment

[aditya.sreekumar@gmail.com (JIRA)]

Adity Sreekumar edited a comment on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

When was the _$\{params.Name}_ syntax introduced? It does not seem to detect that when I use it in the following context:

\ { \{ code:java}

parameters \ { string ( defaultValue: '1.0', description: 'Toolchain version', name : 'TOOLCHAIN') } steps \ {    checkout ($class: 'GitSCM', branches = [[name: '$ \\ {params.TOOLCHAIN}']]]) } }}

{code}   If I use just TOOLCHAIN, it gives me the error reported earlier where it cannot find the environment variable.

Add Comment

[aditya.sreekumar@gmail.com (JIRA)]

[stefan.verhoeff@here.com (JIRA)]

Stefan Verhoeff commented on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

Adity Sreekumar I think the issue in your code are the single quotes. Use double quotes instead to make variable interpolation work.   [[name: "$\{params.TOOLCHAIN}"]]]

Add Comment

[stefan.verhoeff@here.com (JIRA)]

Stefan Verhoeff edited a comment on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

[~asreekumar] I think the issue in your code are the single quotes. Use double quotes instead to make variable interpolation work.   {{[[name: "$\{params.TOOLCHAIN}"]]]}}

Add Comment

[stefan.verhoeff@here.com (JIRA)]

Stefan Verhoeff edited a comment on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

[~asreekumar] I think the issue in your code are the single quotes. Use double quotes instead to make variable interpolation work.

{ { noformat} [[name: "$ \ {params.TOOLCHAIN}"]]] {noformat } }

Add Comment

[aditya.sreekumar@gmail.com (JIRA)]

Adity Sreekumar commented on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

That worked, thanks.

Add Comment

[pashev.igor@gmail.com (JIRA)]

Igor Pashev commented on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

There is a similar issue with triggers. I do not know how this works, but with declarative syntax the fix could be as simple as parsing the pipeline definition and picking up triggers and parameters. After all this work with good old XML configs that are perfectly declarative too.

Add Comment

This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)

[pashev.igor@gmail.com (JIRA)]

Igor Pashev edited a comment on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

There is a similar issue with triggers. I do not know how this works, but with declarative syntax the fix could be as simple as parsing the pipeline definition and picking up triggers and parameters.

After all this work works with good old XML configs that are perfectly declarative too.

Add Comment

[pashev.igor@gmail.com (JIRA)]

Igor Pashev commented on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

At least I'd like it fixed for inline piplines (not in SCM repositories). Pipelines offer some useful feature like parallel steps, multiple SCM, etc. which are not available in old XML configs. This problem with triggers and parameters is definitely a regression.

Add Comment

[jglick@cloudbees.com (JIRA)]

Jesse Glick commented on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

I'd like it fixed for inline piplines (not in SCM repositories). Just define the trigger, parameters, or other job properties directly on the job, as you would have for freestyle. This works for both inline scripts and scripts from SCM. You only need to use the properties step and thus encounter this issue when you are using multibranch projects (a.k.a. “Pipeline-as-Code”).

Add Comment

[jglick@cloudbees.com (JIRA)]

Jesse Glick updated an issue

Jenkins / JENKINS-41929

Offer "Build with Parameters" on first build when declarative Jenkinsfile found

Change By: Jesse Glick Labels: multibranch

Add Comment

[pashev.igor@gmail.com (JIRA)]

Igor Pashev commented on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

> Just define the trigger, parameters, or other job properties directly on the job, as you would have for freestyle. This works for both inline scripts and scripts from SCM

Looks like it really works!

Add Comment

[patrickruhkopf@gmail.com (JIRA)]

Patrick Ruhkopf commented on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

There seems to be a more critical issue when using parameterized, declarative pipelines within shared libraries and multi-branch projects. When there were modifications and a change is pushed from SCM, then the build fails immediately with the following exception: java.lang.IllegalArgumentException: Null value not allowed as an environment variable: APPLICATION at hudson.EnvVars.put(EnvVars.java:359) at hudson.model.StringParameterValue.buildEnvironment(StringParameterValue.java:59) at hudson.model.ParametersAction.buildEnvironment(ParametersAction.java:145) at hudson.model.Run.getEnvironment(Run.java:2365) at org.jenkinsci.plugins.workflow.job.WorkflowRun.getEnvironment(WorkflowRun.java:513) at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:106) at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:120) at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:303) When the pipeline is in this state, the only fix is to manually trigger it with "Run with parameters". I can't use any of the workarounds suggested here, because even with a pipeline consisting of a single "echo hello world" it fails right away. Any suggestions? Does this belong here in this issue or should I open a new one?

Add Comment

[patrickruhkopf@gmail.com (JIRA)]

Patrick Ruhkopf edited a comment on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

There seems to be a more critical issue when using parameterized, declarative pipelines within shared libraries and multi-branch projects. When there were modifications and a change is pushed from SCM, then the build fails immediately with the following exception:

{code: java } java .lang.IllegalArgumentException: Null value not allowed as an environment variable: APPLICATION

at hudson.EnvVars.put(EnvVars.java:359) at hudson.model.StringParameterValue.buildEnvironment(StringParameterValue.java:59) at hudson.model.ParametersAction.buildEnvironment(ParametersAction.java:145) at hudson.model.Run.getEnvironment(Run.java:2365) at org.jenkinsci.plugins.workflow.job.WorkflowRun.getEnvironment(WorkflowRun.java:513) at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:106) at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:120)

at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:303) {code}

When the pipeline is in this state, the only fix is to manually trigger it with "Run with parameters". I can't use any of the workarounds suggested here, because even with a pipeline consisting of a single "echo hello world" it fails right away. Any suggestions? Does this belong here in this issue or should I open a new one?

Add Comment

[patrickruhkopf@gmail.com (JIRA)]

Patrick Ruhkopf edited a comment on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

There seems to be a more critical issue when using parameterized, declarative pipelines within shared libraries and multi-branch projects. When there were modifications and a change is pushed from SCM, then the build fails immediately with the following exception: {code:java}

java.lang.IllegalArgumentException: Null value not allowed as an environment variable: APPLICATION

at hudson.EnvVars.put(EnvVars.java:359) at hudson.model.StringParameterValue.buildEnvironment(StringParameterValue.java:59) at hudson.model.ParametersAction.buildEnvironment(ParametersAction.java:145) at hudson.model.Run.getEnvironment(Run.java:2365) at org.jenkinsci.plugins.workflow.job.WorkflowRun.getEnvironment(WorkflowRun.java:513) at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:106) at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:120) at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:303) {code}

When the pipeline is in this state, the only fix is to manually trigger it with "Run with parameters". I can't use any of the workarounds suggested here, because even with a when I update the Jenkinsfile to not call the shared pipeline consisting of and just print a single "echo hello world" , it still fails right away. Any suggestions?

Does this belong here in this issue or should I open a new one?

Add Comment

[andrew.bayer@gmail.com (JIRA)]

Andrew Bayer commented on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

Patrick Ruhkopf - open a new ticket and make sure to include your full reproduction case. I assume you don't have a default value set for the parameter in question?

Add Comment

[f.modler@gmx.net (JIRA)]

Falko Modler commented on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

I am also affected by this: Jenkinsfile from SCM string parameter with defaultValue value is accessed via ${params.[...]} changed defaultValue is only picked up in the second build, not right away

Add Comment

This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

[kuisathaverat@gmail.com (JIRA)]

Ivan Fernandez Calvo commented on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

The workaround seems not valid on the latest version of declarative pipeline, even do you use params to declare the environment variable the variable is not defined Jenkins core 2.153 Declarative Pipeline 1.3.3 Steps to replicate the issue: Create a Jenkinsfile like the following in a repo Create a multibranch pipeline that uses this repo and this Jenkinsfile Create a PR Check the logs of the pipeline and you could see the issue, the variable is not defined on parallel stages #!/usr/bin/env groovy pipeline { agent none options { timeout(time: 1, unit: 'HOURS') buildDiscarder(logRotator(numToKeepStr: '20', artifactNumToKeepStr: '20', daysToKeepStr: '30')) timestamps() ansiColor('xterm') disableResume() durabilityHint('PERFORMANCE_OPTIMIZED') } parameters { string(name: 'GO_VERSION', defaultValue: "1.10.3", description: "Go version to use.") } stages { stage('Initializing'){ agent { label 'linux && immutable' } options { skipDefaultCheckout() } environment { GO_VERSION = "${params.GO_VERSION}" } stages { stage('It works') { steps { sh "echo '${GO_VERSION}'" } } } stage('Test') { failFast true parallel { stage('Fail 01') { steps { sh "echo '${GO_VERSION}'" } } stage('Fail 02') { steps { sh "echo '${GO_VERSION}'" } } } } } } This works pipeline { agent none options { timeout(time: 1, unit: 'HOURS') buildDiscarder(logRotator(numToKeepStr: '20', artifactNumToKeepStr: '20', daysToKeepStr: '30')) timestamps() ansiColor('xterm') disableResume() durabilityHint('PERFORMANCE_OPTIMIZED') } parameters { string(name: 'GO_VERSION', defaultValue: "1.10.3", description: "Go version to use.") } stages { stage('Initializing'){ agent { label 'linux && immutable' } options { skipDefaultCheckout() } environment { GO_VERSION = "${params.GO_VERSION}" } stages { stage('It works') { steps { sh "echo '${GO_VERSION}'" } } } stage('Test') { failFast true parallel { stage('Fail 01') { environment { GO_VERSION = "${params.GO_VERSION}" } steps { sh "echo '${GO_VERSION}'" } } stage('Fail 02') { environment { GO_VERSION = "${params.GO_VERSION}" } steps { sh "echo '${GO_VERSION}'" } } } } } }

Add Comment

[kuisathaverat@gmail.com (JIRA)]

Ivan Fernandez Calvo edited a comment on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

The workaround seems not valid on the latest version of declarative pipeline, even do you use params to declare the environment variable the variable is not defined

* Jenkins core 2.153 * Declarative Pipeline 1.3.3

Steps to replicate the issue:

* Create a Jenkinsfile like the following in a repo * Create a multibranch pipeline that uses this repo and this Jenkinsfile * Create a PR * Check the logs of the pipeline and you could see the issue, the variable is not defined on parallel stages {code}

{code} This works {code}

{code}

Add Comment

[steve.bussetti@gmail.com (JIRA)]

steve bussetti commented on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

Has there been any traction on this?  Honestly if someone could point me at the code responsible for reading the Jenkinsfile from the scm I could write a simple plugin that just adds a "Refresh Job Definition" button to the sidebar of a job. Most of the folks I see run into this are less concerned with the first-time triggered build than they are about being unable to modify new parameters after updating a particular job which means they're manually executing a Pipeline.

Add Comment

[hkawashi@gmail.com (JIRA)]

Hideaki Kawashima commented on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

Is this bug known to the person in charge ? Are you already working on countermeasures ? The specification that can specify the default value in parameters block is broken. Various provisional workarounds are listed, but they will fail immediately. As mentioned above, re-definition in the environment block is not possible in parallel execution. Script compilation fails if the number of parameters defined in the parameters block is large or the script is slightly larger. Expecting a default setting a build with Jenkins with default settings defined in parameters block for post-commit processing, but we have to go to the build manually after first build failed. (This wreck automation for build pipeline) I'd like to see clear countermeasures or workarounds soon. Thank you.

Add Comment

[hkawashi@gmail.com (JIRA)]

Hideaki Kawashima edited a comment on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

Is this bug known to the person in charge ? Are you already working on countermeasures ? The specification that can specify the default value in parameters block is broken. Various provisional workarounds are listed, but they will fail immediately.

As mentioned above, re-definition in the environment block is not possible in parallel execution. Script compilation fails if the number of parameters defined in the parameters block is large or the script is slightly larger. Expecting a default setting a first build with Jenkins with default settings defined in parameters block for post-commit processing, but we have to go to the build manually after first build failed. (This wreck automation for build pipeline) As you know, there are many different builds in the CI environment for post-commit processing. Rerunning them one by one manually will greatly impair the significance of the existence of a CI environment that is designed to reduce time and effort.

I'd like to see clear countermeasures or workarounds soon. Thank you.

Add Comment

[hkawashi@gmail.com (JIRA)]

Hideaki Kawashima edited a comment on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

Is this bug known to the person in charge ? Are you already working on countermeasures ? The specification that can specify the default value in parameters block is broken. Various provisional workarounds are listed, but they will fail immediately.

As mentioned above, re-definition in the environment block is not possible in parallel execution. Script compilation fails if the number of parameters defined in the parameters block is large or the script is slightly larger. Expecting a first build with default settings defined in parameters block for post-commit processing, but we have to go to the build manually after failed. (This wreck automation breaks automate execution for build pipeline)

As you know, there are many different builds in the CI environment for post-commit processing. Rerunning them one by one manually will greatly impair the significance of the existence of a CI environment that is designed to reduce time and effort. I'd like to see clear countermeasures or workarounds soon. Thank you.

Add Comment

[marcello.romani.enit@gmail.com (JIRA)]

Marcello Romani commented on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

[...] adds a "Refresh Job Definition" button to the sidebar of a job. That doesn't sound like a bad idea...

Add Comment

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

[privat@michaelbrunner.de (JIRA)]

Michael Brunner commented on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

Here my workaround: I've added pipeline options skipDefaultCheckout true and in the first stage the following script script { // On first build by user just load the parameters as they are not available of first run on new branches if (env.BUILD_NUMBER.equals("1") && currentBuild.getBuildCauses('hudson.model.Cause$UserIdCause') != null) { currentBuild.displayName = 'Parameter loading' addBuildDescription('Please restart pipeline') currentBuild.result = 'ABORTED' error('Stopping initial manually triggered build as we only want to get the parameters') } } So first time pressing the button does not lead to a build but a parameter loading. Perhaps I can find a solution, where it is triggered automatically on branch creation by scm. Any ideas?

Add Comment

[allan.lewis@youview.com (JIRA)]

Allan Lewis commented on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

Thanks, Michael Brunner - I've considered doing something similar, except maybe making it SCM-triggered since my pipeline is designed to only be manually triggered.

Add Comment

[paul.frischknecht@bit.admin.ch (JIRA)]

Paul Frischknecht commented on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

I would like to bring this issue to your attention again. We have many pseudo-failing builds on our Jenkins because of this, which renders the "Weather Icon" build state monitoring tool useless. Also, DevOps are confused when they first see "Build now" when they expect "Build with Parameters" which they see only after that first build failed... Andrew Bayer, Jesse Glick

Add Comment

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

[paul.frischknecht@bit.admin.ch (JIRA)]

Paul Frischknecht edited a comment on JENKINS-41929

Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found

I would like to bring this issue to your attention again. We have many pseudo-failing builds on our Jenkins (we are hundreds of developers...) because of this, which renders the "Weather Icon" build state monitoring tool useless. Also, DevOps are confused when they first see "Build now" when they expect "Build with Parameters" which they see only after that first build failed... [~abayer], [~jglick]

Add Comment