I am setting up several build jobs in Jenkins and I find myself repeating the same API keys and paths in every script. Is there a way to define global environment variables that all jobs can access? Additionally, I need some variables to be specific only to a certain project folder. Should I be using the Global Properties in the system configuration, or is there a better way to handle this through the Jenkinsfile to keep my configuration as code?
3 answers
For variables that need to be accessed globally, you should navigate to "Manage Jenkins" > "System" (formerly Configure System) and look for the "Global properties" section. By checking the "Environment variables" box, you can add key-value pairs that become available to every single node and job in your Jenkins instance. However, if you are moving toward a "Pipeline as Code" model, it is better to define them directly in your Jenkinsfile using the environment { ... } block. This ensures that your variables are version-controlled alongside your source code. If you have sensitive data like passwords, always use the "Credentials" plugin and the withCredentials wrapper rather than plain text environment variables to ensure your security remains intact.
If I define a variable globally in the system settings, but then define a variable with the same name inside a specific Jenkinsfile, which one takes precedence during the build execution?
I suggest using the "Folder-level" environment variables if you use the Folders plugin. It’s a great middle-ground between global and job-level scopes for multi-team setups
I agree with Nancy. On my last project, we used the Folder-level properties to set the target AWS region for the entire mobile team without affecting the web team's jobs. It kept our global config clean while providing the necessary automation for that specific group of projects.
Steven, the local definition will always override the global one. Jenkins follows a specific hierarchy: the environment variables defined in the Pipeline (environment block) have the highest priority, followed by job-specific parameters, and finally the global properties defined in the system configuration. This allows you to set "sane defaults" globally while allowing individual projects to customize their behavior as needed for specific environments.