[JIRA] (JENKINS-60559) Job string parameters are unpredictably changed

[k.jankowski@partner.samsung.com (JIRA)]

Kornel Jankowski created an issue

Jenkins / JENKINS-60559 Job string parameters are unpredictably changed Issue Type: Bug Assignee: Unassigned Components: core Created: 2019-12-20 14:19 Priority: Blocker Reporter: Kornel Jankowski 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 `LANGUAGE` parameter) now randomly start to misbehave - the parameter `language` isn't even set.     Add Comment

This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)

[k.jankowski@partner.samsung.com (JIRA)]

Kornel Jankowski updated an issue

Jenkins / JENKINS-60559 Job string parameters are unpredictably changed

Change By: Kornel Jankowski

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

{code:java}

echo language $language echo LANGUAGE $LANGUAGE

{code}

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

{code:java} LANGUAGE=zu-UO language=sa-TN {code} The output is: {code:java} language LANGUAGE sa-TN {code} While it should be {code:java} language sa-TN LANGUAGE zu-UO{code}

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:

{code:java} language=sa-TN LANGUAGE=zu-UO {code}

The output is DIFFERENT! this time:

{code:java} language sa-TN LANGUAGE {code}

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

{code:java} language sa-TN LANGUAGE zu-UO {code}

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 `LANGUAGE` parameter * so there cannot be a upper-lower-case collision ) now randomly start to misbehave - the parameter `language` isn't even set.

Add Comment

[k.jankowski@partner.samsung.com (JIRA)]

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` parameter * ** so there cannot be a upper-lower-case collision) now randomly start to misbehave - the parameter `language` isn't even set.

Add Comment

[k.jankowski@partner.samsung.com (JIRA)]

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.

Add Comment