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

Job string parameters are unpredictably changed

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Blocker Blocker
    • core
    • None

      I create a freestyle job, which runs a trivial shell script:

      echo language $language
      echo LANGUAGE $LANGUAGE
      

      I create it as a freestyle job with two string parameters (`LANGUAGE` and `language`).
      When I set the parameters (using the GUI configurator) to:

      LANGUAGE=zu-UO
      language=sa-TN
      

      The output is:

      language
      LANGUAGE sa-TN
      

      While it should be

      language sa-TN
      LANGUAGE zu-UO

      And what's more: when i configure the same parameter values, but the order of parameters in the job configuration is reverse (yes, I just dragged one and moved it in the GUI), and so I set:

      language=sa-TN
      LANGUAGE=zu-UO
      

      The output is DIFFERENT! this time:

      language sa-TN
      LANGUAGE
      

      Which, anyway, is still wrong, though, as it still should be:

      language sa-TN
      LANGUAGE zu-UO
      

      This happens on a clean setup with default plugins prepared in a docker container from your dockerhub, both on current lts (2.204.1) and on latest (2.209).

      At this point, I simply do not now how to configure my jobs' parameters.
      Within my real setup (currently on 2.176.3) jobs that used to successfully work when configured with a parameter named `language` (even if there is no uppercase parameter named `LANGUAGE`** so there cannot be a upper-lower-case collision) now randomly start to misbehave - the parameter `language` isn't even set. Changing anything (even totally unrelated) in a job configuration results in blowing up a working configuration where the 'language' variable has been used for a long time without any problems.

       

       

          [JENKINS-60559] Job string parameters are unpredictably changed

          Rens Groothuijsen added a comment - - edited

          This appears to be an intentional behavior, as EnvVars uses a case-insensitive comparator . Not entirely certain why though.

          Rens Groothuijsen added a comment - - edited This appears to be an intentional behavior, as EnvVars uses a case-insensitive comparator  . Not entirely certain why though.

          Indeed, given that env variable names are by definition case-sensitive, it seems like an original and not straightforwardly explicable choice.

          Kornel Jankowski added a comment - Indeed, given that env variable names are by definition case-sensitive, it seems like an original and not straightforwardly explicable choice.

          This is likely because windows apis handle env variables in a case insensitive manner

          Raihaan Shouhell added a comment - This is likely because windows apis handle env variables in a case insensitive manner

          Well, if Windows treats environment variables different than real operating systems, they should be treated differently here too, shouldn't they? Or, o.i.w., they should be case-sensitive on Unix-like systems.

          Dirk Heinrichs added a comment - Well, if Windows treats environment variables different than real operating systems, they should be treated differently here too, shouldn't they? Or, o.i.w., they should be case-sensitive on Unix-like systems.

            rensgroothuijsen Rens Groothuijsen
            kjankowski Kornel Jankowski
            Votes:
            3 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated: