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

Windows paths are no longer correctly passed in the parameters

    XMLWordPrintable

Details

    Description

      When upgrading form the 1.x to the latest 2.x version we noticed that now the backslash characters are interpreted as special characters in the passed parameter value.
      We used to pass our workspace as parameter to the different jobs and now this path gets mangled, so we had to revert the upgrade. Apparently somewhere logic got added to do an interpretation of the value being passed as parameter.
      Could this behaviour be fixed or at least be made so that one can choose if the expansion needs to happen or not.

      Attachments

        Activity

          sorokh sorokh created issue -
          mindless Alan Harder added a comment -

          Looking into this.. I think it's a side-effect of allowing $OTHER_PARAM references in the parameters text. Expansion of these variables is affecting the backslashes (presumably so you could put \$OTHER_PARAM to avoid parameter expansion and get literal text $OTHER_PARAM).

          mindless Alan Harder added a comment - Looking into this.. I think it's a side-effect of allowing $OTHER_PARAM references in the parameters text. Expansion of these variables is affecting the backslashes (presumably so you could put \$OTHER_PARAM to avoid parameter expansion and get literal text $OTHER_PARAM).
          mindless Alan Harder added a comment -

          No, on further checking the Hudson EnvVars class uses $$ to avoid expansion, not \$. It is reading the text as java Properties format that is doing stuff with backslashes.

          mindless Alan Harder added a comment - No, on further checking the Hudson EnvVars class uses $$ to avoid expansion, not \$. It is reading the text as java Properties format that is doing stuff with backslashes.
          mindless Alan Harder added a comment -

          The content here in a "Predefined parameters" entry is specified to be in Java properties format, so I don't think we can do anything about the handling of backslashes. I will add a note about backslashes in the help text for that field.

          mindless Alan Harder added a comment - The content here in a "Predefined parameters" entry is specified to be in Java properties format, so I don't think we can do anything about the handling of backslashes. I will add a note about backslashes in the help text for that field.
          mindless Alan Harder made changes -
          Field Original Value New Value
          Assignee huybrechts [ huybrechts ] mindless [ mindless ]

          Code changed in hudson
          User: : mindless
          Path:
          trunk/hudson/plugins/parameterized-trigger/src/main/java/hudson/plugins/parameterizedtrigger/PredefinedBuildParameters.java
          trunk/hudson/plugins/parameterized-trigger/src/main/webapp/help/properties.html
          http://jenkins-ci.org/commit/33342
          Log:
          [parameterized-trigger] [FIXED JENKINS-6004] Expand parameter references in
          "Predefined parameters" on a value-by-value basis AFTER reading the text in
          java properties format, to avoid mangling of values containing backslashes.
          This means putting $FOO in the text where FOO is "ABC=123\nDEF=456" will
          no longer expand into separate ABC and DEF parameter to pass along.
          However, it fixes a case like MYWS=$WORKSPACE on windows, as the backslash
          characters in the path will no longer be lost.
          Also added a note in the help text for this field about backslashes.

          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : mindless Path: trunk/hudson/plugins/parameterized-trigger/src/main/java/hudson/plugins/parameterizedtrigger/PredefinedBuildParameters.java trunk/hudson/plugins/parameterized-trigger/src/main/webapp/help/properties.html http://jenkins-ci.org/commit/33342 Log: [parameterized-trigger] [FIXED JENKINS-6004] Expand parameter references in "Predefined parameters" on a value-by-value basis AFTER reading the text in java properties format, to avoid mangling of values containing backslashes. This means putting $FOO in the text where FOO is "ABC=123\nDEF=456" will no longer expand into separate ABC and DEF parameter to pass along. However, it fixes a case like MYWS=$WORKSPACE on windows, as the backslash characters in the path will no longer be lost. Also added a note in the help text for this field about backslashes.
          scm_issue_link SCM/JIRA link daemon made changes -
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Resolved [ 5 ]
          abayer Andrew Bayer made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          rtyler R. Tyler Croy made changes -
          Workflow JNJira [ 136097 ] JNJira + In-Review [ 203851 ]

          People

            mindless Alan Harder
            sorokh sorokh
            Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: