Global environments
Global environments let you normalize environment data across projects and CI pipelines into a consistent set of named variables.
How it works
When test results are uploaded from a CI system, environment data — browser version, platform, host name, and so on — is attached to the launch and to each individual test result. Different pipelines and tools may use different variable names for the same concept: one job calls it TEST_BROWSER, another calls it JENKINS_BROWSER.
Global environments solve this by introducing a canonical variable at the instance level. At the project level, you then map one or more pipeline variables to that canonical name. All of them resolve to the same global variable regardless of where the data came from.
For example:
- Global variable:
browser - Project mappings:
TEST_BROWSER,JENKINS_BROWSER,browser→ all link tobrowser
Why it matters
Once environment data is normalized, it becomes available for:
- filtering launches in search and pre-filters
- filtering test results
- scoping widget data for analytics and dashboards
Without normalization, the same data appears under different names across projects, making cross-project analysis unreliable.
