feat(configuration): bump config schema to v1.1.0, apply Prometheus property rename#6781
Conversation
Bump opentelemetry-configuration schema from v1.0.0 to a SHA on main that includes upcoming v1.1.0 changes. Tracking issue for v1.1.0: open-telemetry/opentelemetry-configuration#643. Pulls in the Prometheus exporter property rename (open-telemetry#612 upstream): - `without_scope_info` -> `scope_info_enabled` (inverted semantics) - `without_target_info/development` -> `target_info_enabled/development` (inverted semantics) - `with_resource_constant_labels` -> `resource_constant_labels` Updates EnvironmentConfigFactory hardcoded defaults and all test fixtures/assertions to match the new schema. Regenerated types and validator. The schema pin should be reverted to a tagged release (v1.1.0) once upstream cuts the release. Assisted-by: Claude Opus 4.6
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #6781 +/- ##
==========================================
+ Coverage 94.93% 95.51% +0.57%
==========================================
Files 383 382 -1
Lines 13009 12941 -68
Branches 2975 2967 -8
==========================================
+ Hits 12350 12360 +10
+ Misses 659 581 -78
🚀 New features to boost your workflow:
|
|
CI failures are:
|
Side Q on versioning the config(Perhaps this doesn't need to be solved for this PR. This "configuration" package and Should a minor release of the configuration schema result in a breaking change of the JS configuration package? Eventually we might want to support multiple major versions of the config schema, but I don't know that for sure. @MikeGoldsmith @maryliag Do you know of prior discussions around this? |
v1.1.0 of opentelemetry-configuration was released on 2026-06-05, which includes the IdGenerator definition and the Prometheus property rename. Switch the codegen pin from the temporary main SHA back to a tagged release. Regenerated types and validator. Assisted-by: Claude Opus 4.6
I'm not aware, and we haven't discussed how we will handle this in the JS |
|
I'm also unaware of any discussion around how implementations could / should support multiple versions of the config spec. The spec shouldn't introduce any breaking changes in minor versions, so major config version to major JS package version makes sense. |
…omments Trent's review feedback on open-telemetry#6781: the eslint config v10 update (open-telemetry#6382) accidentally added the generated config files to the ignore list, so npm run lint:fix in the codegen no longer ran on them. This produced formatting noise in generated types.ts. - Remove the experimental/packages/configuration/src/generated/** ignore from eslint.config.mjs so lint:fix runs on these files - Drop the now-redundant /* eslint-disable */ header in validator.js and validator.d.ts (lint:fix handles formatting; the AUTO-GENERATED comment signals intent) - Regenerate types and validator with the corrected lint Assisted-by: Claude Opus 4.6
Resolve CHANGELOG conflict by keeping the PR's Unreleased breaking change entry alongside the new 0.219.0 release section from main.
…hema-prometheus-rename
trentm
left a comment
There was a problem hiding this comment.
And since we're not yet passing through options to new PrometheusMetricExporter() for env-based config, nor handling meter_provider/readers/*/pull at all in the config, there are no changes needed to sdk-node yet.
trentm
left a comment
There was a problem hiding this comment.
@MikeGoldsmith Oh, wait. Shouldn't this come with changing over the file_format guard to require "1.1" and all test and example config files to use file_format: "1.1" as at https://github.com/open-telemetry/opentelemetry-configuration/blob/main/examples/otel-getting-started.yaml#L11?
Bumping the schema to v1.1.0 should accept config files declaring `file_format: "1.1"`. Widen the guard to accept any 1.x minor (1.0 and 1.1), since minor versions are backward compatible. Move all test/example fixtures to "1.1" and add explicit coverage for 1.0 acceptance and unsupported-major rejection.
Yep, you are right. I've updated the version checks to allow both 1.0 and 1.1. Thanks 👍🏻 |
Follow the configuration versioning spec: reject a config file whose MAJOR version differs, accept any MINOR version within the supported major, and warn (rather than reject) when the MINOR version is newer than this SDK targets. Mirrors the opentelemetry-python behaviour.
|
|
||
| ### :boom: Breaking Changes | ||
|
|
||
| * chore(configuration)!: bump config schema to v1.1.0; rename `without_scope_info` → `scope_info_enabled` and `without_target_info/development` → `target_info_enabled/development` on the Prometheus pull exporter (semantics inverted), rename `with_resource_constant_labels` → `resource_constant_labels`. Validate `file_format` per the configuration versioning spec: accept any minor version of major `1` (e.g. `1.0`, `1.1`), warn when the minor version is newer than supported, and reject other major versions. [#6781](https://github.com/open-telemetry/opentelemetry-js/pull/6781) @MikeGoldsmith |
There was a problem hiding this comment.
Q: is this breaking now? It might not be.
There was a problem hiding this comment.
Technically it is a breaking change for anyone who was using prometheus/development config out of the parsed model. However, given that model and the whole config package is experimental and moving from an rc to a stable release, maybe could remove the breaking change flag?
There was a problem hiding this comment.
Thanks.
Per the configuration repo's versioning doc, anything */development isn't considered a semver breaking change.
Co-authored-by: Trent Mick <trentm@gmail.com>
Which problem is this PR solving?
The config schema was pinned to v1.0.0 (Feb 2026). v1.1.0 was released on 2026-06-05, which includes the Prometheus exporter property rename, IdGenerator definition, and other improvements.
Short description of the changes
Bumps the config schema pin from
v1.0.0tov1.1.0. The most user-visible change is the Prometheus exporter property rename (open-telemetry/opentelemetry-configuration#612 upstream):without_scope_info→scope_info_enabled(inverted semantics:false→true)without_target_info/development→target_info_enabled/development(inverted semantics:false→true)with_resource_constant_labels→resource_constant_labelsChanges:
CONFIG_VERSIONin the codegen script tov1.1.0EnvironmentConfigFactoryhardcoded Prometheus defaults to use the new property names with inverted semanticskitchen-sink.yaml) and assertions to matchBreaking change?
For OTel JS consumers using the
configurationpackage directly, the renamed properties onprometheus/developmentare a breaking change. Marked!per convention.Type of change
How Has This Been Tested?
tsc --buildcompiles cleanly