You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/AccessEnvironmentVariables.md
+11-2Lines changed: 11 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -63,7 +63,9 @@ The configuration inversion system works as follows:
63
63
64
64
To add support for a new environment variable:
65
65
66
-
### Step 1: Add to supported-configurations.json
66
+
### Step 1: Add to supported-configurations.json & central registry
67
+
68
+
If the configuration key has never been registered by any tracer it needs to be added to the [Configuration Registry](https://feature-parity.us1.prod.dog/#/configurations?viewType=configurations) (available only for internal contributors) with proper documentation. In the case of an already existing key the behavior needs to be verified in order to know if a new version of the same key needs to be created on the registry.
67
69
68
70
Edit the `supported-configurations.json` file and add your variable (Please keep any new keys in the file sorted!):
69
71
@@ -80,18 +82,20 @@ Edit the `supported-configurations.json` file and add your variable (Please keep
80
82
#### Configuration Structure
81
83
82
84
-**supportedConfigurations**: Maps variable names to configuration metadata
83
-
-`version`: (Currently always set to `["A"]`) Array indicating which implementations the tracer supports. Implementations are defined in the Feature Parity Dashboard and multiple implementations could be set for a single environment variable (e.g. the base one `A`, and an extra one `B` that adds new possible values). Versions are non-numeric to avoid confusion with library versions.
85
+
-`version`: (Defaults to `["A"]`) Array indicating which implementations the tracer supports. Implementations are defined in the Configuration Registry and multiple implementations could be set for a single environment variable (e.g. the base one `A`, and an extra one `B` that adds new possible values). Versions are non-numeric to avoid confusion with library versions.
84
86
85
87
In the future, the structure will also contain more information such as the type, the default value...
86
88
87
89
-**aliases**: Maps canonical variable names to arrays of alias names
90
+
88
91
```json
89
92
"aliases": {
90
93
"DD_SERVICE": ["OTEL_SERVICE_NAME"]
91
94
}
92
95
```
93
96
94
97
-**deprecations**: Adds a log message to deprecated environment variables.
98
+
95
99
```json
96
100
"deprecations": {
97
101
"DD_OLD_VARIABLE": "Please use DD_NEW_VARIABLE",
@@ -151,6 +155,10 @@ rescue RuntimeError => e
151
155
end
152
156
```
153
157
158
+
### CI jobs
159
+
160
+
The `validate_supported_configurations_local_file` CI job in charge of validating the content of the `supported-configurations.json` file against the central Configuration Registry runs on GitLab. This job verifies that all configuration keys present in the local file are correctly registered on the central registry. When a new key is introduced it has to be registered in order to pass this job.
161
+
154
162
## Validation
155
163
156
164
To ensure your configuration changes are valid:
@@ -159,6 +167,7 @@ To ensure your configuration changes are valid:
159
167
# Validate that generated assets match the JSON file
This will also be run by the main RSpec rake task.
163
172
164
173
This task will exit with an error if there's a mismatch between `supported-configurations.json` and the generated assets. It is run by the CI, thus a mismatch will make the CI fail.
0 commit comments