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
            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.
            Hide
            paulfrischknecht Paul Frischknecht added a comment - - edited

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

            Andrew Bayer, Jesse Glick

            Show
            paulfrischknecht Paul Frischknecht added a comment - - edited 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... Andrew Bayer , Jesse Glick

              People

              • Assignee:
                Unassigned
                Reporter:
                jglick Jesse Glick
              • Votes:
                120 Vote for this issue
                Watchers:
                130 Start watching this issue

                Dates

                • Created:
                  Updated: