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

Allow use of double quoted strings for pipeline variables

    Details

    • Similar Issues:
    • Sprint:
      Blue Ocean - Candidates

      Description

      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

        Attachments

          Activity

          Hide
          jamesdumay James Dumay added a comment -

          This is on the roadmap to fix.

          Show
          jamesdumay James Dumay added a comment - This is on the roadmap to fix.
          Hide
          kzantow Keith Zantow added a comment -

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

          Show
          kzantow Keith Zantow added a comment - James Dumay JENKINS-41548 is fixed so round tripping works properly now, but there's no way to enter double-quoted strings from the editor, still.
          Hide
          jamesdumay 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?

          Show
          jamesdumay 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?
          Hide
          kzantow 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...

          Show
          kzantow 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...
          Hide
          bitwiseman Liam Newman added a comment -

          James Dumay Keith Zantow

          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? 

          Show
          bitwiseman Liam Newman added a comment - James Dumay Keith Zantow 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? 

            People

            • Assignee:
              Unassigned
              Reporter:
              michaelneale Michael Neale
            • Votes:
              1 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated: