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

Jenkins escapes 2 dollar signs in the Parameterized Build fields

    XMLWordPrintable

    Details

    • Similar Issues:

      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

            Hide
            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?

            Show
            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?
            Hide
            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")
            Show
            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" )
            Hide
            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.

            Show
            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.
            Hide
            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

            Show
            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
            Hide
            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.

            Show
            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.
            Hide
            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...

            Show
            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...
            Hide
            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}"
                  }
                }
              }
            }
            
            Show
            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

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

                Dates

                Created:
                Updated: