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

Environment variable name created from File Parameter → File Location contains the "directory name portion" though stated differently in its inline help

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      The title says it. Since I don't like to repeat myself please have a look at my answer to "How to trigger downstream jenkins job with File parameter as parameter?" at StackOverflow.

      Suggested actions:

      • Don't add the path name portion, according to what's stated in the inline help
      • Revise the inline help:
        • Don't state a file with an extension (abc.zip at the time of this writing) as an example
        • Add a note that strongly recommends to only use characters in File Location's file name that are officially supported for environment variable names by the OS Jenkins or its slaves are currently running on

        Attachments

          Activity

          Hide
          danielbeck Daniel Beck added a comment -

          Don't add the path name portion, according to what's stated in the inline help

          Breaking change. so I'd rather just fix the docs. Having the full path as specified in the parameter should be more useful anyway.

          Show
          danielbeck Daniel Beck added a comment - Don't add the path name portion, according to what's stated in the inline help Breaking change. so I'd rather just fix the docs. Having the full path as specified in the parameter should be more useful anyway.
          Hide
          geri Gerold Broser added a comment - - edited

          @Daniel Beck

          Having the full path as specified in the parameter should be more useful anyway.

          Did you follow the link to the answer I gave on SO? Have you seen the link to IEEE Std 1003.1, 2013 Edition there?

          Environment variable names used by the utilities in the Shell and Utilities volume of POSIX.1-2008 consist solely of uppercase letters, digits, and the <underscore> ( '_' ) [...]

          I agree that a path in the File Location parameter is useful (to store the uploaed file there rather than in the workspace).

          I disagree in having '.' or '/' (or ':' or '\', I didn't test this with Windows) in the resulting variable name since this is against the standard implemented in OSs largely spread worldwide.

          Show
          geri Gerold Broser added a comment - - edited @ Daniel Beck Having the full path as specified in the parameter should be more useful anyway. Did you follow the link to the answer I gave on SO? Have you seen the link to IEEE Std 1003.1, 2013 Edition there? Environment variable names used by the utilities in the Shell and Utilities volume of POSIX.1-2008 consist solely of uppercase letters, digits, and the <underscore> ( '_' ) [...] I agree that a path in the File Location parameter is useful (to store the uploaed file there rather than in the workspace). I disagree in having '.' or '/' (or ':' or '\', I didn't test this with Windows) in the resulting variable name since this is against the standard implemented in OSs largely spread worldwide.
          Hide
          danielbeck Daniel Beck added a comment -

          We should find out whether the current implementation can be used by anyone while using sub directories. Not everything is POSIX, and not everything is a shell either, and only then these restrictions seem to apply. As a cross-platform tool, Jenkins should aim for the lowest common denominator only where necessary IMO.

          Right now, it just means there's an unusable environment variable, and only if the job is configured by the user in a specific a way. Looks to me like minor loss of functionality with easy workaround present.

          Show
          danielbeck Daniel Beck added a comment - We should find out whether the current implementation can be used by anyone while using sub directories. Not everything is POSIX, and not everything is a shell either, and only then these restrictions seem to apply. As a cross-platform tool, Jenkins should aim for the lowest common denominator only where necessary IMO. Right now, it just means there's an unusable environment variable, and only if the job is configured by the user in a specific a way. Looks to me like minor loss of functionality with easy workaround present.

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            geri Gerold Broser
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated: