I am in the process of upgrading a Jenkins installation and scripted pipeline that is a few years behind.
A part of the build process is currently dependent on dynamically generated EnvVars keys that have “-” and/or “.” in the string.
In the older configuration (the bottom setup) these values are making it into the shell environment and are visible to a gradle process calling System.getenv().
In the newer configuration, they are never reaching the shell environment.
i.e.
env.“bad-var” = “true”
echo sh(returnStdout: true, script: ‘printenv|sort’)
shows bad-var in the printed env variables on the older configuration, but is absent in the new setup.
Any guidance on understanding how the old configuration may be bypassing OS level env var restrictions would be greatly appreciated.
Jenkins setup(s):
containers built from:
jenkins/jenkins:lts-slim-jdk17
jenkins/ssh-agent:latest-bullseye-jdk17
Jenkins: 2.462.1
OS: Linux - 5.15.153.1-microsoft-standard-WSL2
Java: 17.0.12 - Eclipse Adoptium (OpenJDK 64-Bit Server VM)
Jenkins: 2.462.1
OS: Linux - 5.4.17-2136.333.5.1.el8uek.x86_64
Java: 17.0.12 - Eclipse Adoptium (OpenJDK 64-Bit Server VM)
Not containerized.
Jenkins: 2.332.3
OS: Linux - 5.14.21-150500.55.68-default
Java: 1.8.0_422 - IcedTea (OpenJDK 64-Bit Server VM)
The issue you’re encountering is likely due to changes in how environment variables are handled by the underlying OS and JDK versions.
Sounds fishy to me, but specifically, environment variables with characters like - and . may not be supported in newer configurations due to stricter enforcement of naming conventions.
Here are some steps that may help with addressing this issue:
Convert the problematic characters in your environment variable names to underscores or another acceptable character.
Create a wrapper script that sets the environment variables with sanitized names and then maps them back to the original names within the script.
the “exec env” was necessary for spawned processes to inherit the env vars set.
If a single process is involved, “env” would have been sufficient, I think.