Source build version from shared metadata.version#326
Merged
gh-worker-dd-mergequeue-cf854d[bot] merged 6 commits intomasterfrom May 8, 2026
Merged
Conversation
Contributor
Author
This stack of pull requests is managed by Graphite. Learn more about stacking. |
5 tasks
watson
force-pushed
the
watson/DEBUG-5465/inject-version-at-runtime
branch
from
eb80c25 to
a800ced
Compare
tylfin
approved these changes
Apr 27, 2026
Expose the configured `liveDebugger.version` in the injected runtime bootstrap so the Browser Debugger SDK can default its runtime version from build metadata. Move the bootstrap logic into a dedicated helper and document the new behavior.
The deployed build identifier is a cross-plugin concern rather than a Live Debugger one. Move it from `liveDebugger.version` onto the shared `metadata.version` field, alongside the existing `metadata.name`. Type-validation of the shared `metadata` block is centralized in the factory's `validateOptions`, so consumers don't each re-implement it. Only `metadata.version` is validated today: a TODO in factory/validate.ts flags that `metadata.name` should also be tightened in the next major, since the root README has long documented its default as `null`, and adding the check now would break users who took that literally. The Live-Debugger-specific invariant — `metadata.version` must match `errorTracking.sourcemaps.releaseVersion` when both are configured — stays in the live-debugger validator, since that's the plugin enforcing it.
watson
force-pushed
the
watson/DEBUG-5465/inject-version-at-runtime
branch
from
a800ced to
eeba682
Compare
watson
changed the title
Have `errorTracking.sourcemaps.releaseVersion` and `rum.sourceCodeContext.version` fall back to the shared `metadata.version` when no plugin-specific value is configured. Users who declare the build version once at the top level no longer need to repeat it under each plugin namespace. To support the fallback, `SourcemapsOptions.releaseVersion` is loosened from required to optional. The existing "is required" check still fires when neither `sourcemaps.releaseVersion` nor `metadata.version` resolves, with an updated message that mentions both options. Document `metadata.version` as a top-level option in the root README so it sits alongside `metadata.name`, and update the auto-generated configuration block template in `@dd/tools` accordingly.
watson
changed the title
yoannmoinet
reviewed
Apr 29, 2026
Member
yoannmoinet
left a comment
yoannmoinet
left a comment
There was a problem hiding this comment.
I'm not sure I understand why the errorTracking concern is handled by the liveDebugger plugin.
I don't think these two plugins should know anything about each others.
Comment on lines
+106
to
+109
| // Build the resolved config only when `releaseVersion` actually | ||
| // resolves; otherwise an error has been recorded and the caller will | ||
| // throw before the config is read. | ||
| if (releaseVersion) { |
Member
There was a problem hiding this comment.
Not sure this if () {} wrapping is really necessary.
It brings more confusion when reading the code than anything.
Even the comment tends to explain that it's actually unnecessary since it would throw anyways.
Contributor
Author
There was a problem hiding this comment.
I think it's best to keep the code as-is because releaseVersion might be undefined and if we don't have this if-guard, we get a TypeScript error below because it's not allowed to be undefined in that context. If you have a better fix for this, let me know.
This was referenced Apr 30, 2026
Move metadata.version and sourcemap release version mismatch validation into the error-tracking plugin so Live Debugger no longer depends on Error Tracking configuration details.
Remove the Live Debugger README note that describes cross-plugin metadata validation while keeping the source map version guidance.
Use the shared logger mock and separate valid option fixtures from intentionally invalid runtime config shapes in validation tests.
Contributor
Author
|
/merge |
|
View all feedbacks in Devflow UI.
The expected merge time in
|
gh-worker-dd-devflow-36fce6
Bot
added
mergequeue-status: queued
mergequeue-status: in_progress
and removed
mergequeue-status: queued
labels
gh-worker-dd-mergequeue-cf854d
Bot
deleted the
watson/DEBUG-5465/inject-version-at-runtime
branch
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What and why?
This PR makes
metadata.versionthe canonical place to declare the deployed build identifier across the Datadog build plugins. Three plugins now read from it:versionduringinit()— keeping browser build lookup and source-code resolution working without extra SDK wiring.errorTracking.sourcemaps.releaseVersion) falls back to it when no plugin-specific value is set.rum.sourceCodeContext.version) falls back to it when no plugin-specific value is set.Users who declare the build version once at the top level no longer need to repeat it under each plugin namespace. The change is additive: existing per-plugin configurations keep working unchanged.
This builds on #325, which introduced build-time validation of the version but stopped short of using it at runtime.
How?
BuildMetadata(in@dd/core/types) gains an optionalversion?: string, alongside the existingname. The root README documents it as a top-level option, and the auto-generated configuration block template in@dd/toolsis updated to include it.metadata.*is centralized in the factory'svalidateOptions. Today it strictly type-checksmetadata.version. A TODO flagsmetadata.nameto be tightened in the next major — its documented default is currentlynull, so adding the check now would be a breaking change.metadata.versionmust matcherrorTracking.sourcemaps.releaseVersionwhen both are explicitly configured.runtime-bootstraphelper. The bootstrap installs the minimal$dd_probesno-op stub, and whenmetadata.versionis set it also exposes build metadata on a runtime-visible global so the Browser Debugger SDK can default itsversionfrom there duringinit().SourcemapsOptions.releaseVersionis loosened from required to optional. The existing "is required" check still fires when neithersourcemaps.releaseVersionnormetadata.versionresolves, with an updated message that mentions both options.