[JENKINS-73991] withEnv does not alert when env var name is not valid

[jenkins-infra-bot]

I mistakenly tried to setting an env var which is not valid in a linux environment, e.g. :

withEnv([
    parallel-build='-j 12'
])

It is clearly not possible to create a linux env var with a variable name containing a dash.

The result is that the env var is not set, If some other env var are set in withEnv, they are not set and the pipeline can goes on without any warning.

There should have at least a warning written in the console log, and I think that as environment variables can be considered as critical data for a pipeline, the pipeline should be stopped.

---

Originally reported by jielpe_fr38, imported from: withEnv does not alert when env var name is not valid

• status: Open
• priority: Minor
• component(s): workflow-basic-steps-plugin
• resolution: Unresolved
• votes: 0
• watchers: 2
• imported: 20251215-220547

Raw content of original issue

I mistakenly tried to setting an env var which is not valid in a linux environment, e.g. :

withEnv([
    parallel-build='-j 12'
])


It is clearly not possible to create a linux env var with a variable name containing a dash.
The result is that the env var is not set, If some other env var are set in withEnv, they are not set and the pipeline can goes on without any warning.
There should have at least a warning written in the console log, and I think that as environment variables can be considered as critical data for a pipeline, the pipeline should be stopped.

environment

Jenkins : 2.462.2 LTS (alpine based docker image)<br/>
workflow-basic-steps-plugin : 1058.vcb_fc1e3a_21a_9

[jenkins-infra-bot]

vpotyarkin:

• Original comment link
• Raw content of original comment:

  POSIX imposes very little restrictions on characters allowed in environment variable names. The behavior you describe is to be expected and `withEnv` likely succeeds in setting the variable - you just can not read it with common shells (but still can read it from other processes).
  
  I've downgraded the priority to Minor because I don't think that this report warrants any action. Suggested warning is better suited for something like pipeline linter (Do such linters exist? I'd like to have one)
  

POSIX imposes very little restrictions on characters allowed in environment variable names. The behavior you describe is to be expected and `withEnv` likely succeeds in setting the variable - you just can not read it with common shells (but still can read it from other processes).

I've downgraded the priority to Minor because I don't think that this report warrants any action. Suggested warning is better suited for something like pipeline linter (Do such linters exist? I'd like to have one)