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

Job string parameters are unpredictably changed

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Blocker
    • Resolution: Unresolved
    • Component/s: core
    • Labels:
      None
    • Similar Issues:

      Description

      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.

       

       

        Attachments

          Activity

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

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

          Show
          kjankowski 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.
          Hide
          raihaan Raihaan Shouhell added a comment -

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

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

            People

            Assignee:
            rensgroothuijsen Rens Groothuijsen
            Reporter:
            kjankowski Kornel Jankowski
            Votes:
            2 Vote for this issue
            Watchers:
            7 Start watching this issue

              Dates

              Created:
              Updated: