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

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

    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
            sbussetti steve bussetti added a comment -

            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.  

            Show
            sbussetti steve bussetti added a comment - 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.  
            Hide
            hkawashi Hideaki Kawashima added a comment - - edited

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

            Show
            hkawashi Hideaki Kawashima added a comment - - edited 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 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.
            Hide
            marcello_romani Marcello Romani added a comment -

            [...] adds a "Refresh Job Definition" button to the sidebar of a job.

            That doesn't sound like a bad idea...

            Show
            marcello_romani Marcello Romani added a comment - [...] adds a "Refresh Job Definition" button to the sidebar of a job. That doesn't sound like a bad idea...
            Hide
            brunni Michael Brunner added a comment -

            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?

            Show
            brunni Michael Brunner added a comment - 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?
            Hide
            allanlewis_youview Allan Lewis added a comment -

            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.

            Show
            allanlewis_youview Allan Lewis added a comment - 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.

              People

              • Assignee:
                abayer Andrew Bayer
                Reporter:
                jglick Jesse Glick
              • Votes:
                113 Vote for this issue
                Watchers:
                124 Start watching this issue

                Dates

                • Created:
                  Updated: