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
            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
            Hide
            jpik Jonathan Piché added a comment -

            I believe this issue extends into a more serious issue, and I haven't found a pattern that works with Jenkins yet... This issue applies to "Multibranch" pipeline jobs, but also to simple "Pipeline" jobs.

            Imagine a simple publish job that is used by many different repositories. This job is called from other jobs. In order to provide the most reproducible solution, the other job must provide the commit id of the generic jenkinsfile to use (e.g.: $COMMIT = v2.4). This is then used in the "Clone" properties of the job config (through the UI) as "Branch to checkout: $COMMIT".

            This works well: Jenkins receives $COMMIT, and uses that to checkout "a jenkinsfile from the past" and process it.

            This works well, as long as you don't add/remove properties

            If I released a new v2.5 with a new property, I cannot support the v2.4 properties because then, when other jobs calls me with 2.4 or before, the new property will be deleted. This affects both the "Build with Parameter" method, AND through `build job:  job_name` from another jenkinsfile.

             

            I can think of 2 workarounds:

            1. Create a new job with a new name each time the properties change
            2. Leverage the multibranch pipeline so that it discovers a special branch prefix like `jenkins/` that you use to publish new versions of the jenkinsfile

             

            None of my workaround fix the "first time run" problem, but the real problem here, is that you can't call 100% reproducible builds is jenkins has to rely on some artifact from the previous build in order to work. This is probably the root of all evils...?

             

            Is there a more general issue that I should subscribe to in order to monitor the progress on the chicken & egg problem?

            Show
            jpik Jonathan Piché added a comment - I believe this issue extends into a more serious issue, and I haven't found a pattern that works with Jenkins yet... This issue applies to "Multibranch" pipeline jobs, but also to simple "Pipeline" jobs. Imagine a simple publish job that is used by many different repositories. This job is called from other jobs. In order to provide the most reproducible solution, the other job must provide the commit id of the generic jenkinsfile to use (e.g.: $COMMIT = v2.4). This is then used in the "Clone" properties of the job config (through the UI) as "Branch to checkout: $COMMIT". This works well: Jenkins receives $COMMIT, and uses that to checkout "a jenkinsfile from the past" and process it. This works well, as long as you don't add/remove properties If I released a new v2.5 with a new property, I cannot support the v2.4 properties because then, when other jobs calls me with 2.4 or before, the new property will be deleted. This affects both the "Build with Parameter" method, AND through `build job:  job_name` from another jenkinsfile.   I can think of 2 workarounds: Create a new job with a new name each time the properties change Leverage the multibranch pipeline so that it discovers a special branch prefix like `jenkins/` that you use to publish new versions of the jenkinsfile   None of my workaround fix the "first time run" problem, but the real problem here, is that you can't call 100% reproducible builds is jenkins has to rely on some artifact from the previous build in order to work. This is probably the root of all evils...?   Is there a more general issue that I should subscribe to in order to monitor the progress on the chicken & egg problem?
            Hide
            jglick Jesse Glick added a comment -

            There is no more general issue, it is just inherent to using a properties step as part of the build itself, as opposed to some sort of external job (re)definition such as the job-dsl plugin.

            Show
            jglick Jesse Glick added a comment - There is no more general issue, it is just inherent to using a properties step as part of the build itself, as opposed to some sort of external job (re)definition such as the job-dsl plugin.

              People

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

                Dates

                • Created:
                  Updated: