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

Parameters default to last ones provided in UI, instead of the one provided inside the Jenkinsfile

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: blueocean-plugin
    • Environment:
    • Epic Link:
    • Sprint:
      Blue Ocean - Candidates
    • Similar Issues:

      Description

      Summary:
      Given a Jenkinsfile with a parameters block in it, it's possible to have parameters with default settings defined. When a run is started, the user will be shown the parameters, and given the chance to change them. In the Classic UI, the default value is always set to whatever is in the Jenkinsfile. But in Blue Ocean, the default value is set to whatever the user attempted previously.

      Frequency:
      100% of the time.

      Steps to recreate:
      1. Create a Jenkinsfile in a remote repository, with a parameters section defined. In this, use a string parameter to define the agent label on which you want the Pipeline to run. In my case, this is linux, and I have a remote agent connected with that label assigned:

          parameters {
              string(name: 'String parameter with spaces', defaultValue: 'Fill me in with something witty!', description: 'This is a string parameter, yo!')
              booleanParam(name: 'TRUE_OR_FALSE', defaultValue: true, description: 'This boolean defaults to true!') 
              string(name: 'AGENT_NAME', defaultValue: 'linux', description: 'Where to run')
          }
      

      2. Because of JENKINS-41929, you will need to have run, and then canceled, this Pipeline at least once. Otherwise it'll try to run on an agent of label null, and we know that won't work.

      3. In the Classic UI, when you run this Pipeline, the screen will look like this. It's here that you can change that AGENT_NAME to whatever you like.

      4. Here's the same screen in Blue Ocean, and I've set AGENT_NAME to the value bogus_thing. This won't work, and that's fine.

      5. Click Run, and monitor the build. You'll eventually want to cancel this run, since there's no such agent. This is also fine.

      6. After stopping the ill-fated run you kicked off in step 5, click the Run triangle again. This is the issue: notice that the AGENT_NAME label is set to what you previously changed it to. It should say linux, which is what's in the Jenkinsfile:

      7. This behavior feels incorrect for a couple of reasons. Mostly, because it's not really honoring the default setting you've provided in the Jenkinsfile. Secondarily, the Classic UI always defaults to whatever the Jenkinsfile says. Same exact steps, done entirely through Classic, produce this screen every time:

      8. While writing this up, I decided to try different kinds of parameters. And they are all affected by this same issue: they default to whatever the user last did in Blue Ocean, as opposed to defaulting to the values listed in the Jenkinsfile. Example:

        Attachments

          Activity

          Hide
          jamesdumay James Dumay added a comment -

          Sounds like we are not calling the right API here. WDYT Vivek Pandey?

          Show
          jamesdumay James Dumay added a comment - Sounds like we are not calling the right API here. WDYT Vivek Pandey ?
          Hide
          kshultz Karl Shultz added a comment -

          Testing Notes:
          Automated creation tests should walk through the steps provided above. Basically:

          • Job do-something-neat has some editable settings when the job is started
          • Those settings have defaults built into them
          • Test performs a run of do-something-neat, and uses non-default settings
          • Re-run do-something-neat, and verify that the default settings are the ones first filled in. In other words, the second run doesn't "remember" the last settings provided.
          Show
          kshultz Karl Shultz added a comment - Testing Notes: Automated creation tests should walk through the steps provided above. Basically: Job do-something-neat has some editable settings when the job is started Those settings have defaults built into them Test performs a run of do-something-neat , and uses non-default settings Re-run do-something-neat , and verify that the default settings are the ones first filled in. In other words, the second run doesn't "remember" the last settings provided.
          Hide
          kkkuba Jakub Michalec added a comment - - edited

          any chance for fixing that? or any known workaround other than input step?

           

          edit:

          It's looks like jenkins caching default values, refresh page help

          Show
          kkkuba Jakub Michalec added a comment - - edited any chance for fixing that? or any known workaround other than input step?   edit: It's looks like jenkins caching default values, refresh page help

            People

            • Assignee:
              vivek Vivek Pandey
              Reporter:
              kshultz Karl Shultz
            • Votes:
              2 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated: