Details
-
Type:
Bug
-
Status: Reopened (View Workflow)
-
Priority:
Major
-
Resolution: Unresolved
-
Labels:None
-
Similar Issues:
Description
I use Jenkins Pipeline with "Pipeline Script from SCM".
In my pipeline script, there is a parameters definition. When I change the parameters in my Jenkinsfile and push the changes to my SCM, the new parameters are not shown up in Jenkins when I click "build with parameters". I have to run the job once with the old configuration and afterwards the new parameters show up.
It would be great if you can provide a possibility to "reload" the Pipeline script (with its new parameters) from scm without executing the Job, e.g. adding a button "reload Jenkinsfile".
Attachments
Issue Links
- is duplicated by
-
JENKINS-41929 Offer "Build with Parameters" on first build when declarative Jenkinsfile found
-
- Open
-
-
JENKINS-52939 Need to lint pipeline from UI, and also parse parameters
-
- Open
-
Activity
How is this fixed? I do not see a link to a closed issue that addresses the problem.
Jonathan McCall
added a comment - How is this fixed? I do not see a link to a closed issue that addresses the problem. 
I am also interested in how this was resolved.
Ashley Campbell
added a comment - I am also interested in how this was resolved. it will be great to have this feature instead of rebuld the job in order to get the latest Params from the pipeline script
dor s
added a comment - it will be great to have this feature instead of rebuld the job in order to get the latest Params from the pipeline script This is a major problem, a hole, in the pipeline feature. The workaround is lame: run the pipeline after modifying the jenkinsfile (in source control); kill the job as soon as Jenkins has processed the updated jenkinsfile which seems to happen right after it pulls the code at the start of the job; then run again.
I realize that this is not trivial to fix. Jenkins needs to load the jenkinsfile from source control; so it has to know exactly where to find it. For example, I usually set the git branch to a parameter so that you can choose the branch at job start time. So, to run a job, Jenkins would need to know the branch, load the jenkinsfile, then present the parameters from that file. That's alot to ask for ... since the branch may be parameter driven ... circularity.
For this, Jenkins would need to treat branch as a special parameter - not a custom parameter.
Note that azure devops does not have this problem. It loads the pipeline configuration file after you select a source branch.
A complication is that although I'm using and talking about git, there are other source control systems. So, a general purpose solution would require changes for each source control system.
Could consider a different feature that is much easier to implement, is not a good as what I describe above, but is much better than current functionality. Add a way (button) to reload the jenkinsfile params. Would need to present the existing params since one may include the branch name. Could add the button on the start job view. In addition to the (poorly named) "Build" button, add a button named like "reload jenkinsfile". It would load the jenkinsfile from source control and update the cached parameter config. The user would remain on the build start view with updated parameters.
steve
added a comment - - edited This is a major problem, a hole, in the pipeline feature. The workaround is lame: run the pipeline after modifying the jenkinsfile (in source control); kill the job as soon as Jenkins has processed the updated jenkinsfile which seems to happen right after it pulls the code at the start of the job; then run again.
I realize that this is not trivial to fix. Jenkins needs to load the jenkinsfile from source control; so it has to know exactly where to find it. For example, I usually set the git branch to a parameter so that you can choose the branch at job start time. So, to run a job, Jenkins would need to know the branch, load the jenkinsfile, then present the parameters from that file. That's alot to ask for ... since the branch may be parameter driven ... circularity.
For this, Jenkins would need to treat branch as a special parameter - not a custom parameter.
Note that azure devops does not have this problem. It loads the pipeline configuration file after you select a source branch.
A complication is that although I'm using and talking about git, there are other source control systems. So, a general purpose solution would require changes for each source control system.
Could consider a different feature that is much easier to implement, is not a good as what I describe above, but is much better than current functionality. Add a way (button) to reload the jenkinsfile params. Would need to present the existing params since one may include the branch name. Could add the button on the start job view. In addition to the (poorly named) "Build" button, add a button named like "reload jenkinsfile". It would load the jenkinsfile from source control and update the cached parameter config. The user would remain on the build start view with updated parameters. 
Would the aspect that "parameters are in Jenkinsfile, but don't get used when I run the project" make this considered a bug?