Finding filters via Phase 1 of .weaver.toml config file by jerbly · Pull Request #1256 · open-telemetry/weaver

jerbly · 2026-03-01T02:44:48Z

Adds .weaver.toml project-level config, completing Phase 1 of the package-vs-project config proposal. Discovery walks up from CWD; --config <path> overrides. Precedence: defaults -> .weaver.toml -> CLI flags.

Phase 1 (live-check)

[live_check] covers every live-check CLI flag, including [live_check.otlp] and [live_check.emit] sub-tables.
[[live_check.finding_filters]] drops findings by id, sample name, level, or signal type.

Phase 2 PoC

Partial shared sections ([registry], [policy], [diagnostics]) included so live-check is end-to-end usable. Wired through a temporary heuristic and marked with a TODO — the proper rework converts the shared *Args structs to Option<T> and adopts the standard CliOverrides pattern uniformly.

Infrastructure

weaver_config crate split into live_check, registry, and overrides modules.
CliOverrides trait + override_if_set! macro: generic IoC pattern subcommands can adopt with one impl.
Automatic CLI/config consistency test: schemars + clap introspection catches drift between config fields and CLI args. Generic helper — future commands opt in with one line.
JSON schema at schemas/weaver-config.json. Use the #:schema directive at the top of .weaver.toml for editor autocomplete. Regenerate via weaver registry json-schema --json-schema weaver-config.

See the Finding Modification section in the live-check README for usage details.

codecov · 2026-03-01T03:04:18Z

Codecov Report

❌ Patch coverage is 83.92857% with 18 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.8%. Comparing base (7b63ef9) to head (3c598b0).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
crates/weaver_live_check/src/lib.rs	68.1%	7 Missing ⚠️
crates/weaver_config/src/overrides.rs	0.0%	6 Missing ⚠️
crates/weaver_config/src/lib.rs	76.1%	5 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #1256     +/-   ##
=======================================
- Coverage   81.9%   81.8%   -0.1%     
=======================================
  Files        115     119      +4     
  Lines       9850    9938     +88     
=======================================
+ Hits        8069    8137     +68     
- Misses      1781    1801     +20

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

jsuereth

I love the direction, but soft-blocking.

I think we need to understand what WeaverConfig of today is meant to do vs. this.
We should figure out if toml vs. yaml is ok
It's possible we want a formal split between WeaverPackageConfig and WeaverRuntimeConfig. I can buy that, but let's not use confusing names between crates here.

jerbly · 2026-03-02T14:42:09Z

TBH, I've never read the comment at the top of the weaver_forge config.rs - I totally didn't realise it was meant to be used for weaver configuration in general! My bad!

I think we need to understand what WeaverConfig of today is meant to do vs. this.

Yes! I would like to understand that. I've always seen the weaver.yaml files belonging to the jinja template processes, not belonging to the instance of weaver you're running. Indeed, weaver.yaml today is found from the templates directory, not CWD. The separation of templates versus runtime (until now) has been in command-line options - the way I see it.

We should figure out if toml vs. yaml is ok

We can do yaml - I was just following the crowd for linters etc. If we're somehow combining this with weaver.yaml then, of course we should stay on yaml.

It's possible we want a formal split between WeaverPackageConfig and WeaverRuntimeConfig. I can buy that, but let's not use confusing names between crates here.

This is much better than my confusing reuse of the name, and follows my thoughts on "what the config belongs to". We would have to clarify both. But, now I've read the weaver_forge config.rs in more detail I'm not sure what we should be doing. 😕

jerbly · 2026-03-02T16:23:08Z

I just looked deeper at the weaver_forge config.rs. It uses a merging strategy walking up the dir tree from the template directory and merging any weaver.yaml it finds up to root. Then it adds the one from home dir. The merge happens in reverse order of the walk, therefore the weaver.yaml in the template dir takes precedence. However, if your templates are remote (not in your local filesystem) then ONLY the weaver.yaml in the remote location is loaded. Not even your home-dir weaver.yaml is merged.

Merging configs would be error-prone for runtime/CLI type settings versus the first-wins strategy. I can see how it makes sense for templates - but we seem to have a mix within the template world anyway with local versus remote.

jerbly · 2026-03-02T17:55:33Z

...and... registry update-markdown has different behaviour to registry generate. The former only loads the weaver.yaml in the template dir, whereas the latter does the tree walk and home-dir merge (provided the template dir is in the local filesystem).

jsuereth · 2026-03-03T00:32:03Z

...and... registry update-markdown has different behaviour to registry generate. The former only loads the weaver.yaml in the template dir, whereas the latter does the tree walk and home-dir merge (provided the template dir is in the local filesystem).

Yeah -

I think we probably want to consistently differentiate between "package" config which lives with the template / rego policy package and "project / local" config, where walking the home directory makes sense.

I can clearly understand a world where templates have their own configuration.

We likely need the ability to influence that configuration, even for remote templates, which is what @lquerel was tyring to do, e.g. I use a shared template package, but I want to set certain params or override a few defaults.

Woudl it be worth putting together a quick proposal PR @jerbly on what you think we should do?

…dot-weaver

jerbly · 2026-03-04T00:48:12Z

Woudl it be worth putting together a quick proposal PR @jerbly on what you think we should do?

#1260

lquerel · 2026-03-04T07:47:48Z

@jerbly @jsuereth I’m a big fan of #1260 - I added a few suggestions that I think stay aligned with the overall idea.

…dot-weaver

…emented properly in phase 2.

…Overrides pattern

…stryArgs

…dot-weaver

jsuereth · 2026-04-16T17:10:30Z

+/// The field-mapping methods (`config_only_fields`, `cli_only_args`,
+/// `field_mappings`) enable a generic consistency test that verifies every
+/// config field has a CLI arg and vice versa, with no per-command test code.
+pub trait CliOverrides {


Should we have CliOverrides<T: "Config"> here?

E.g. do we envision overriding different config types via the same CLI argument?

jsuereth · 2026-04-16T17:25:20Z

+#[derive(Debug, Clone, Default, Deserialize, PartialEq, JsonSchema)]
+#[serde(default)]
+#[schemars(inline)]
+pub struct RegistryConfig {


Note: This is a non-blocking comment, but something that's been noodling in my head for a while.

If we moved live-check to a mode where it dynamically downloaded schema_url on-demand based on what it sees in telemetry - what would this config look like?

Would this instead be some kind of a schema-url -> config map? Curious on your thoughts - I was toying around with trying to get AI to make this change and it started floundering with complexity, so I think this is one we'd need to talk through our architecture for.

jsuereth · 2026-04-16T17:27:14Z

+/// - `override_if_set!(dst, src)` — for `Option<T> → T` (clone into existing value)
+/// - `override_if_set!(dst, src, optional)` — for `Option<T> → Option<T>` (wrap in `Some`)
+#[macro_export]
+macro_rules! override_if_set {


There's a lot of this in the attribute/signal inheritance code - I wonder if we should move this to common eventually to share?

jsuereth

Approving this as a good first start - caveat I do think the weaver.yoml syntax is somethign I'm worried about. I think we should issue a warning that the schema is not stable if folks use it for now, until we're happy with how it handles things.

You can see my comments on things I'm worried about breaking in the future.

finding modifications

1e85914

jerbly requested a review from a team as a code owner March 1, 2026 02:44

readme and external types

09d7119

jerbly mentioned this pull request Mar 1, 2026

Live check dog-fooding: doc, code-gen and live-check #1232

Merged

refactor

57847ff

jsuereth reviewed Mar 2, 2026

View reviewed changes

Comment thread crates/weaver_config/src/lib.rs

Comment thread crates/weaver_config/src/lib.rs

Comment thread crates/weaver_config/README.md

jerbly added 2 commits March 2, 2026 21:57

added exclude_samples

69d4105

Merge branch 'main' of https://github.com/open-telemetry/weaver into …

f4fd244

…dot-weaver

jerbly mentioned this pull request Mar 5, 2026

Package vs Project proposal #1260

Merged

jerbly added 7 commits April 9, 2026 21:17

Merge branch 'main' of https://github.com/open-telemetry/weaver into …

30b8903

…dot-weaver

live-check config and finding filters

ad4fad7

PoC for shared args: registry, policy and diagnostics. Will be reimpl…

7dbec92

…emented properly in phase 2.

docs: add TODO for reworking PolicyArgs config application to use Cli…

59fe325

…Overrides pattern

refactor: use constants for default values in DiagnosticArgs and Regi…

a7b01f8

…stryArgs

Merge branch 'main' of https://github.com/open-telemetry/weaver into …

5f78b7e

…dot-weaver

docs

313cdcd

jerbly changed the title ~~Finding overrides and filters via a config file~~ Finding filters via Phase 1 of .weaver.toml config file Apr 12, 2026

jsuereth reviewed Apr 16, 2026

View reviewed changes

jsuereth approved these changes Apr 16, 2026

View reviewed changes

jerbly added 2 commits April 19, 2026 18:30

Merge branch 'main' of github.com:open-telemetry/weaver into dot-weaver

1884a7c

add Experimental warning

43542f7

github-advanced-security AI found potential problems Apr 20, 2026

View reviewed changes

Comment thread src/registry/mod.rs Fixed

Comment thread src/registry/mod.rs Fixed

clippy

3c598b0

jerbly merged commit db0ec1b into open-telemetry:main Apr 20, 2026
26 checks passed

Uh oh!

Conversation

jerbly commented Mar 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Phase 1 (live-check)

Phase 2 PoC

Infrastructure

Uh oh!

codecov Bot commented Mar 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

jsuereth left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jerbly commented Mar 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jerbly commented Mar 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jerbly commented Mar 2, 2026

Uh oh!

jsuereth commented Mar 3, 2026

Uh oh!

jerbly commented Mar 4, 2026

Uh oh!

lquerel commented Mar 4, 2026

Uh oh!

jsuereth Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

jsuereth Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

jsuereth Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

jsuereth left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

jerbly commented Mar 1, 2026 •

edited

Loading

codecov Bot commented Mar 1, 2026 •

edited

Loading

jerbly commented Mar 2, 2026 •

edited

Loading

jerbly commented Mar 2, 2026 •

edited

Loading