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

Allow use of double quoted strings for pipeline variables

    • Blue Ocean - Candidates

      Problem
      For some steps, such as notifications, it is pretty common to want to be able to get to pipeline variables (as opposed to environment variables). 

      In pipeline text this generally means you use double quotes, and string interpolation in the parameters, howrever the editor uses single quotes and avoids groovy string expansion. 

      It would be nice to be able to allow dynamic double quoted strings as an option somehow. 

      Steps to reproduce

      • Use a notification step - try to get the pipeline name into the message string
      • Use an environment variable, try to use "credentials('abc')" to fetch the cred value (it will only be literally what you type in)

      Out of scope: 

      • A UI to select available pipeline variables

          [JENKINS-43951] Allow use of double quoted strings for pipeline variables

          Michael Neale added a comment -

          kzantow to do it at execution time would mean changing declarative - so that it always does an extra pass on literal strings (vs double quoted) right? Potentially risky... 

          I see now you can refer to env variables the same way if they are double quoted or single (however if it is missing a var and it is double quoted, you get a stack trace, vs an empty variable..)

          abayer looking for inspiration here: how do we know, or ask the user, the intent to use double or single quoted strings in declarative? if you had to tell people to use one by default, what would you say? 

          Michael Neale added a comment - kzantow to do it at execution time would mean changing declarative - so that it always does an extra pass on literal strings (vs double quoted) right? Potentially risky...  I see now you can refer to env variables the same way if they are double quoted or single (however if it is missing a var and it is double quoted, you get a stack trace, vs an empty variable..) abayer looking for inspiration here: how do we know, or ask the user, the intent to use double or single quoted strings in declarative? if you had to tell people to use one by default, what would you say? 

          Michael Neale added a comment -

          hrm alternative "opinionated" solution: make environment variables double quote always to allow for expansion, then you can set vars to be values needed, and use them in scripts/args as needed...

          Michael Neale added a comment - hrm alternative "opinionated" solution: make environment variables double quote always to allow for expansion, then you can set vars to be values needed, and use them in scripts/args as needed...

          Furai added a comment -

          I've run into related issue today. I had in my Jenkinsfile some interpolated strings. I've added new step via blue ocean pipeline editor and my pipeline started to fail. It turned out that all the double quote strings got surrounded with single quotes which made interpolation stop working.

          Jenkins 2.60.1, Blue Ocean 1.1.5

          This is the diff just after adding new step through the pipeline editor:

          diff --git a/Jenkinsfile b/Jenkinsfile
          index 95654139..50f7a9ff 100644
          --- a/Jenkinsfile
          +++ b/Jenkinsfile
          @@ -1,16 +1,17 @@
          pipeline {
          agent any
          - options {
          - buildDiscarder(logRotator(artifactDaysToKeepStr: '', artifactNumToKeepStr: '5', daysToKeepStr: '', numToKeepStr: ''))
          - }
          stages {
          stage('Build') {
          steps {
          - zip(zipFile: "build-${currentBuild.id}.zip", archive: true)
          - sh "rm build-${currentBuild.id}.zip"
          + zip(zipFile: '"build-${currentBuild.id}.zip"', archive: true)
          + sh '"rm build-${currentBuild.id}.zip"'
          + echo 'Finishing the build'
          }
          }
          }
          -}
          + options {
          + buildDiscarder(logRotator(artifactDaysToKeepStr: '', artifactNumToKeepStr: '5', daysToKeepStr: '', numToKeepStr: ''))
          + }
          +}
          

           

           

          Furai added a comment - I've run into related issue today. I had in my Jenkinsfile some interpolated strings. I've added new step via blue ocean pipeline editor and my pipeline started to fail. It turned out that all the double quote strings got surrounded with single quotes which made interpolation stop working. Jenkins 2.60.1, Blue Ocean 1.1.5 This is the diff just after adding new step through the pipeline editor: diff --git a/Jenkinsfile b/Jenkinsfile index 95654139..50f7a9ff 100644 --- a/Jenkinsfile +++ b/Jenkinsfile @@ -1,16 +1,17 @@ pipeline { agent any - options { - buildDiscarder(logRotator(artifactDaysToKeepStr: '', artifactNumToKeepStr: ' 5 ', daysToKeepStr: ' ', numToKeepStr: ' ')) - } stages { stage( 'Build' ) { steps { - zip(zipFile: "build-${currentBuild.id}.zip" , archive: true ) - sh "rm build-${currentBuild.id}.zip" + zip(zipFile: ' "build-${currentBuild.id}.zip" ' , archive: true ) + sh ' "rm build-${currentBuild.id}.zip" ' + echo 'Finishing the build' } } } -} + options { + buildDiscarder(logRotator(artifactDaysToKeepStr: '', artifactNumToKeepStr: ' 5 ', daysToKeepStr: ' ', numToKeepStr: ' ')) + } +}    

          Daniel Beck added a comment -

          It turned out that all the double quote strings got surrounded with single quotes which made interpolation stop working.

          Which means that round-tripping existing Jenkinsfiles through the editor is unsafe.

          Daniel Beck added a comment - It turned out that all the double quote strings got surrounded with single quotes which made interpolation stop working. Which means that round-tripping existing Jenkinsfiles through the editor is unsafe.

          James Dumay added a comment -

          This is on the roadmap to fix.

          James Dumay added a comment - This is on the roadmap to fix.

          Keith Zantow added a comment -

          jamesdumay JENKINS-41548 is fixed so round tripping works properly now, but there's no way to enter double-quoted strings from the editor, still.

          Keith Zantow added a comment - jamesdumay JENKINS-41548 is fixed so round tripping works properly now, but there's no way to enter double-quoted strings from the editor, still.

          James Dumay added a comment - - edited

          is that because we default to using ' to quote strings? So I suppose we would need to detect the case where " should be used instead?

          James Dumay added a comment - - edited is that because we default to using ' to quote strings? So I suppose we would need to detect the case where " should be used instead?

          Keith Zantow added a comment -

          Right, the thing is there isn't anything deterministic: e.g. if you enter $USER do you want that resolved at script runtime or passed to the agent verbatim? If we could detect script variables, we could maybe default / prompt the user unobtrusively in some cases, but we can't really get the script variables in any way yet. We could guess certain properties should just always be double quotes (e.g. environment variables, as Michael noted). BUT there's another quite annoying wrinkle: sometimes we want an actual variable / function / etc. yet the flag is only a boolean, not trinary. So, right now round trip is somewhat wacky. A simple example is:

              // in an environment section:
              USER = 'jenkins'
              SYSTEM = "$HOST"
              CREDENTIAL = JAMES
          

          Results in the editor effectively getting this:

              USER = 'jenkins'
              SYSTEM = "$HOST"
              CREDENTIAL = "${JAMES}"
          

          So the single and double quoted strings round-trip properly, but the variable becomes a string expansion. The only way to solve this with the current boolean option is to make users enter double quotes manually but it would still be nigh impossible to deterministically tell what they wanted when entering text...

          Keith Zantow added a comment - Right, the thing is there isn't anything deterministic: e.g. if you enter $USER do you want that resolved at script runtime or passed to the agent verbatim? If we could detect script variables, we could maybe default / prompt the user unobtrusively in some cases, but we can't really get the script variables in any way yet. We could guess certain properties should just always be double quotes (e.g. environment variables, as Michael noted). BUT there's another quite annoying wrinkle: sometimes we want an actual variable / function / etc. yet the flag is only a boolean, not trinary. So, right now round trip is somewhat wacky. A simple example is: // in an environment section: USER = 'jenkins' SYSTEM = "$HOST" CREDENTIAL = JAMES Results in the editor effectively getting this: USER = 'jenkins' SYSTEM = "$HOST" CREDENTIAL = "${JAMES}" So the single and double quoted strings round-trip properly, but the variable becomes a string expansion. The only way to solve this with the current boolean option is to make users enter double quotes manually but it would still be nigh impossible to deterministically tell what they wanted when entering text...

          Liam Newman added a comment -

          jamesdumay kzantow

          Rather than trying to glean what the user wants, how about letting the user tell you what they want. 

          This could be done by adding an "Interploate Variables" option to any step that takes text and forcing all string to double-quote for that step.  

          Or we could add a toggle to the text boxes (maybe have it look like "${}") that indicates if variable interpolation is on.  Right now, it's particularly bad because cause there's nothing in the UI that even indicates what the behavior will be. 

          I see this is marked for 1.4 what the PR? 

          Liam Newman added a comment - jamesdumay kzantow Rather than trying to glean what the user wants, how about letting the user tell you what they want.  This could be done by adding an "Interploate Variables" option to any step that takes text and forcing all string to double-quote for that step.   Or we could add a toggle to the text boxes (maybe have it look like "${}") that indicates if variable interpolation is on.  Right now, it's particularly bad because cause there's nothing in the UI that even indicates what the behavior will be.  I see this is marked for 1.4 what the PR? 

          Chris added a comment -

          Did this get dropped? In our Blue Ocean at work, the Jenkinsfile still gets single-quoted strings, it appears, in anything that isn't a shell step.

          I agree with bitwiseman: let us enter our own quotes. If we use quotes, then keep them the way we give them to you. Write them to Jenkinsfile that way, and when they are pulled back into the editor, display the quotes we originally provided. If we provide neither single nor double quotes, then continue with the current behavior.

          Please? jamesdumay kzantow

          Chris added a comment - Did this get dropped? In our Blue Ocean at work, the Jenkinsfile still gets single-quoted strings, it appears, in anything that isn't a shell step. I agree with bitwiseman : let us enter our own quotes. If we use quotes, then keep them the way we give them to you. Write them to Jenkinsfile that way, and when they are pulled back into the editor, display the quotes we originally provided. If we provide neither single nor double quotes, then continue with the current behavior. Please? jamesdumay kzantow

            Unassigned Unassigned
            michaelneale Michael Neale
            Votes:
            1 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: