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

Jenkins escapes 2 dollar signs in the Parameterized Build fields

    XMLWordPrintable

Details

    Description

      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.

      Attachments

        Issue Links

          Activity

            szhemzhitsky Sergey Zhemzhitsky created issue -
            ircbot Jenkins IRC Bot made changes -
            Field Original Value New Value
            Component/s core [ 15593 ]
            Component/s parameters [ 15594 ]
            danielbeck 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?

            danielbeck 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?
            danielbeck 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")
            danielbeck 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" )
            radle 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.

            radle 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.
            radle Andrey Regentov made changes -
            Link This issue depends on JENKINS-26916 [ JENKINS-26916 ]
            danielbeck Daniel Beck made changes -
            Link This issue is duplicated by JENKINS-26916 [ JENKINS-26916 ]
            chr0n1x 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

            chr0n1x 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
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 146947 ] JNJira + In-Review [ 176771 ]
            ciptchi 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.

            ciptchi 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.
            jantman 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...

            jantman 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 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 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}" } } } }

            People

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

              Dates

                Created:
                Updated: