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

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

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

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

        Attachments

          Issue Links

            Activity

            Hide
            borisivan boris ivan added a comment -

            Brandon Squizzato that's the same thing we did too, though our parameter is "loadParamsAndAbort"

            Show
            borisivan boris ivan added a comment - Brandon Squizzato that's the same thing we did too, though our parameter is "loadParamsAndAbort"
            Hide
            menna_khaled menna khaled added a comment -

            Tim Black I am trying your solution but I am facing an issue, env.BRANCH_NAME is null according to this: https://www.tikalk.com/posts/2017/05/21/how-to-evaluate-git-branch-name-in-a-jenkins-pipeline-using-gitscm/#:~:text=One%20of%20Jenkins%20environment%20variable%20is%20called%20BRANCH_NAME,you%20print%20it%2C%20the%20returned%20value%20is%20%E2%80%98null%E2%80%99. that behavior happens sometimes in pipeline jobs. 
            I understand you just want to rerun the job, so I use env.JOB_NAME and the job is rerun successfully but I am again not prompted to enter parameters. (the behavior we face in 'build now' rather than 'build with parameters')

            Could you please help?

            Show
            menna_khaled menna khaled added a comment - Tim Black  I am trying your solution but I am facing an issue, env.BRANCH_NAME is null according to this: https://www.tikalk.com/posts/2017/05/21/how-to-evaluate-git-branch-name-in-a-jenkins-pipeline-using-gitscm/#:~:text=One%20of%20Jenkins%20environment%20variable%20is%20called%20BRANCH_NAME,you%20print%20it%2C%20the%20returned%20value%20is%20%E2%80%98null%E2%80%99.  that behavior happens sometimes in pipeline jobs.  I understand you just want to rerun the job, so I use env.JOB_NAME and the job is rerun successfully but I am again not prompted to enter parameters. (the behavior we face in 'build now' rather than 'build with parameters') Could you please help?
            Hide
            timblaktu Tim Black added a comment -

            menna khaled if your pipeline does not have `BRANCH_NAME` available, that feels like a problem with your Jenkins/plugin installation/versioning, and I cannot help you with that. I will say however that `BRANCH_NAME` in my example is only used to construct the name of the job to (re-)build using [the build step](https://www.jenkins.io/doc/pipeline/steps/pipeline-build-step/#build-build-a-job), so YMMV: 

             

            Show
            timblaktu Tim Black added a comment - menna khaled  if your pipeline does not have `BRANCH_NAME` available, that feels like a problem with your Jenkins/plugin installation/versioning, and I cannot help you with that. I will say however that `BRANCH_NAME` in my example is only used to construct the name of the job to (re-)build using [the build step] ( https://www.jenkins.io/doc/pipeline/steps/pipeline-build-step/#build-build-a-job ), so YMMV:   
            Hide
            balee balee balee added a comment -

            It might sound a bit unorthodox, but really, isn't there a way to solve this properly (from the point of view of Jenkins users), without messy and inconvenient workarounds?

            For example, if a pipeline is saved (on the UI or with CLI or ...), it might be parsed automagically and look for parameters only and do the same with them as if the job was run? Or actually run the job on save but somehow limited to parameter properties only (and hide the run from the history)? Or...

            I'm sure it is not very simple to implement but it is quite a Major issue...

            Show
            balee balee balee added a comment - It might sound a bit unorthodox, but really, isn't there a way to solve this properly (from the point of view of Jenkins users), without messy and inconvenient workarounds? For example, if a pipeline is saved (on the UI or with CLI or ...), it might be parsed automagically and look for parameters only and do the same with them as if the job was run? Or actually run the job on save but somehow limited to parameter properties only (and hide the run from the history)? Or... I'm sure it is not very simple to implement but it is quite a Major issue...
            Hide
            jglick Jesse Glick added a comment -

            it might be parsed automagically and look for parameters only

            That is exactly what this issue proposes (for Declarative Pipeline).

            Show
            jglick Jesse Glick added a comment - it might be parsed automagically and look for parameters only That is exactly what this issue proposes (for Declarative Pipeline).

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              jglick Jesse Glick
              Votes:
              146 Vote for this issue
              Watchers:
              156 Start watching this issue

                Dates

                Created:
                Updated: