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

Jenkins escapes 2 dollar signs in the Parameterized Build fields

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • core
    • Win 7

      Steps to reproduce:

      1. Create Free Style Build
      2. Check "This build is parameterized" check box
      3. Create two parameters
        1. STR1 with default value Two dollars $$
        2. STR2 with default value One dollar $

      4. In the build section add "Execute Windows batch command" with content

        echo %STR1%
        echo %STR2%
        
      5. Then trigger the build

      Actual result in the console output is

      Two dollars $ 
      One dollar $
      

      Expected result is

      Two dollars $$
      One dollar $
      

      EscapingJexl could be the cause of this issue.

          [JENKINS-16143] Jenkins escapes 2 dollar signs in the Parameterized Build fields

          Daniel Beck added a comment -

          This appears to not be a bug.

          Compare the parameter values $JENKINS_URL and $$JENKINS_URL. Jenkins internally resolves placeholders in variables, and dollars are used for that. $$ is an escaped $.

          I could offer better documentation though, as this behavior does not seem to be documented in the String Parameter's inline help, but should be.

          WDYT?

          Daniel Beck added a comment - This appears to not be a bug. Compare the parameter values $JENKINS_URL and $$JENKINS_URL . Jenkins internally resolves placeholders in variables, and dollars are used for that. $$ is an escaped $ . I could offer better documentation though, as this behavior does not seem to be documented in the String Parameter's inline help, but should be. WDYT?

          Daniel Beck added a comment -

          Relevant Groovy system script (a build step added by Groovy plugin):

          def build = Thread.currentThread().executable
          def tl = new hudson.util.LogTaskListener(java.util.logging.Logger.getLogger("foo"), java.util.logging.Level.INFO)
          println build.getEnvironment(tl).get("STR1")
          println build.getEnvironment(tl).get("STR2")

          Daniel Beck added a comment - Relevant Groovy system script (a build step added by Groovy plugin): def build = Thread .currentThread().executable def tl = new hudson.util.LogTaskListener(java.util.logging.Logger.getLogger( "foo" ), java.util.logging.Level.INFO) println build.getEnvironment(tl).get( "STR1" ) println build.getEnvironment(tl).get( "STR2" )

          Andrey Regentov added a comment - - edited

          Please tell me what should I do to: get the variable with text from TextBox "as is" (i.e. $$ as $$).

          I don't want to resolve variables inside build parameters, I just want to fill file with TextBox contents with something like this in "execute shell":

          echo "$TextParameter" > file
          

          And in the $TextParameter sometimes there are "$" and/or "$$" signs which are to be preserved.

          Andrey Regentov added a comment - - edited Please tell me what should I do to: get the variable with text from TextBox "as is" (i.e. $$ as $$). I don't want to resolve variables inside build parameters, I just want to fill file with TextBox contents with something like this in "execute shell": echo "$TextParameter" > file And in the $TextParameter sometimes there are "$" and/or "$$" signs which are to be preserved.

          Kevin R. added a comment - - edited

          same issue for me too. printing out the shell env (env command) shows that the env var is automatically setting

          value$

          instead of

          value$$

          Jenkins 2.0, CentOS7

          Kevin R. added a comment - - edited same issue for me too. printing out the shell env ( env command) shows that the env var is automatically setting value$ instead of value$$ Jenkins 2.0, CentOS7

          Johannes Abt added a comment - - edited

          Does anyone know where this behaviour is documented? I cannot find anything about this on https://wiki.jenkins.io/display/JENKINS/Parameterized+Build. Did I miss something?

          I wrote down my own experience in https://stackoverflow.com/a/58951240/601203. It's about special handling of whitespace, backslashes and quotes.

          Johannes Abt added a comment - - edited Does anyone know where this behaviour is documented? I cannot find anything about this on  https://wiki.jenkins.io/display/JENKINS/Parameterized+Build . Did I miss something? I wrote down my own experience in  https://stackoverflow.com/a/58951240/601203 . It's about special handling of whitespace, backslashes and quotes.

          Jason Antman added a comment -

          I'm seeing the same behavior happening with the AWS Parameter Store Build Wrapper plugin ( https://plugins.jenkins.io/aws-parameter-store/ ). I don't think the issue here is actually in Parameterized Build, I think it's somewhere in Jenkins core...

          Jason Antman added a comment - I'm seeing the same behavior happening with the AWS Parameter Store Build Wrapper plugin ( https://plugins.jenkins.io/aws-parameter-store/ ). I don't think the issue here is actually in Parameterized Build, I think it's somewhere in Jenkins core...

          Dmitry Lukasevich added a comment - - edited

          Good day,

          Just to note.
          We faced same issue, but we found that declarative pipelines not affected by this interpolation issue.
          So we migrated to parametrized declarative pipeline as follows

          pipeline {
            agent any
            parameters {
              password(name: 'PASSWORD', defaultValue: 'SECRET', description: 'Enter a password')
            }
            stages {
              stage ("Propogating to environment") {
                environment {
                    PASSWORD ="${params.PASSWORD}"
                }
                steps {
                    echo "HURA"
                    echo "Password: ${params.PASSWORD}"
                    echo "Password: ${env.PASSWORD}"
                }
              }
            }
          }
          

          Dmitry Lukasevich added a comment - - edited Good day, Just to note. We faced same issue, but we found that declarative pipelines not affected by this interpolation issue. So we migrated to parametrized declarative pipeline as follows pipeline { agent any parameters { password(name: 'PASSWORD' , defaultValue: 'SECRET' , description: 'Enter a password' ) } stages { stage ( "Propogating to environment" ) { environment { PASSWORD = "${params.PASSWORD}" } steps { echo "HURA" echo "Password: ${params.PASSWORD}" echo "Password: ${env.PASSWORD}" } } } }

            Unassigned Unassigned
            szhemzhitsky Sergey Zhemzhitsky
            Votes:
            2 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: