Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-50365

Reload pipeline script without executing the job

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • core, pipeline
    • None

      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".

          [JENKINS-50365] Reload pipeline script without executing the job

          Would the aspect that "parameters are in Jenkinsfile, but don't get used when I run the project" make this considered a bug?

          Jarrad Whitaker added a comment - Would the aspect that "parameters are in Jenkinsfile, but don't get used when I run the project" make this considered a bug?

          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.

          Geoff Alexander added a comment - - edited

          I also wonder how this is fixed?

          Geoff Alexander added a comment - - edited I also wonder how this is fixed?

          I am also interested in how this was resolved.

          Ashley Campbell added a comment - I am also interested in how this was resolved.

          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

          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

          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.

          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.

          Robert added a comment - - edited

          This has been a great annoyance to us for a while now.

          We've worked around this by adding a checkbox parameter to most of our build jobs which, if checked, triggers all dependent jobs and then fails. That ensures that our pipeline and all dependent build jobs are up to date.

          We don't do it very often, but anytime we do rename a parameter for a build we go through weeks and weeks of failed builds, because we need to support different versions of our software and build parameters will differ between branches.

          Even with the workaround I described above, it takes between 10 and 15 minutes to trigger and reload dependent jobs. It is a very annoying time tax.

          From what I've read, I realize that this seems to be a very complicated requirement, but I would be soooooooooooo happy to see it realized.

          Otherwise, I'm very happy with Jenkins. Keep up the good work.


          Quick update: the latest "reload" took 33 minutes.

          Robert added a comment - - edited This has been a great annoyance to us for a while now. We've worked around this by adding a checkbox parameter to most of our build jobs which, if checked, triggers all dependent jobs and then fails. That ensures that our pipeline and all dependent build jobs are up to date. We don't do it very often, but anytime we do rename a parameter for a build we go through weeks and weeks of failed builds, because we need to support different versions of our software and build parameters will differ between branches. Even with the workaround I described above, it takes between 10 and 15 minutes to trigger and reload dependent jobs. It is a very annoying time tax. From what I've read, I realize that this seems to be a very complicated requirement, but I would be soooooooooooo happy to see it realized. Otherwise, I'm very happy with Jenkins. Keep up the good work. Quick update: the latest "reload" took 33 minutes.

            Unassigned Unassigned
            mrmunch Steffen Becker
            Votes:
            25 Vote for this issue
            Watchers:
            36 Start watching this issue

              Created:
              Updated: