Add weaver-live-check-{start,stop} composite actions#1448
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1448 +/- ##
=======================================
- Coverage 82.2% 82.2% -0.1%
=======================================
Files 125 125
Lines 10241 10241
=======================================
- Hits 8424 8421 -3
- Misses 1817 1820 +3 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
otel-arrow just started using weaver live-check in CI: open-telemetry/otel-arrow#2986. I think that is among the first Once the actions proposed in this PR land, those workflows can be modified to leverage this and reduce boilerplates and ensure better consistency. |
cijothomas
force-pushed
the
cijothomas/weaver-live-check-actions
branch
from
c421b74 to
9be6a0f
Compare
cijothomas
force-pushed
the
cijothomas/weaver-live-check-actions
branch
from
9be6a0f to
20a1dfb
Compare
Pair more symmetrically with weaver-live-check-start. README of the stop action now leads with a note clarifying that 'stop' also collects the report, renders the step summary, and gates the job.
cijothomas
changed the title
jerbly
left a comment
jerbly
left a comment
There was a problem hiding this comment.
This is really nice, thank you!
I have added a few comments, mostly for future improvements. I do think we need a way to see more detail when the run fails though. Let's improve that part a bit and then this will be a great first version.
| Format passed to `weaver registry live-check --diagnostic-format`. | ||
| `gh_workflow_command` surfaces findings as inline GitHub Actions | ||
| annotations. | ||
| required: false |
There was a problem hiding this comment.
It might be worth clarifying in this description that diagnostics are not the live-check findings, but other problems found during the process, e.g. warnings during registry loading.
| icon: 'check-square' | ||
| color: 'blue' | ||
|
|
||
| inputs: |
There was a problem hiding this comment.
In the stats in the report there is a coverage output. It would be good to offer a failure condition for that too. This allows you to check that your registry is being fully exercised by your tests.
| icon: 'play' | ||
| color: 'blue' | ||
|
|
||
| inputs: |
There was a problem hiding this comment.
Could we also have --config here? This allows you to give weaver a toml file of the weaver-config schema. Within that you can configure all the cli parameters and add extra items like:
[[live-check.finding_filters]]
exclude_samples = [
"service.name",
"telemetry.sdk.language",
"telemetry.sdk.name",
"telemetry.sdk.version",
]
| "", | ||
| ] | ||
| if msg_counts: | ||
| summary_lines += [ |
There was a problem hiding this comment.
The summary is nice but it needs more context info to be useful. e.g. the summary produced here: https://github.com/open-telemetry/weaver/actions/runs/26181926973
Is there a way to get the full report? As a user my next step is going to be to dig into exactly what failed.
(Maybe weaver needs to have a mode where it produces the text output for the log AND json on http??)
| (never fail; report-only). Start with `none` when first adopting, | ||
| then tighten once existing findings are addressed. | ||
| required: false | ||
| default: 'violation' |
There was a problem hiding this comment.
Perhaps this should be lifted up into weaver. live-check could return exit code 1 for the failure level selected, not just violation which is the default.
2 participants
Adds two reusable composite actions that wrap the
weaver registry live-checklifecycle for CI integration, mirroring the
setup-weaverpattern:weaver-live-check-start— start the OTLP listener in the background,wait for
/health, expose endpoints as outputs.weaver-live-check-stop—POST /stopto retrieve the report,render a step summary, gate the job on
fail-on(violation|improvement|information|none).Each action has a README and is exercised by a new
test-weaver-live-check-actions.ymlworkflow (parity withtest-setup-weaver-action.yml). Linux runners only in v1.Closes the live-check half of #879 (which produced
setup-weaver).End-to-end prototypes
I wired the actions up in two SDK repos as throw-away prototypes, purely
to validate the flow end-to-end. These are not PRs to those repos —
just personal forks running the actions against real instrumentation
telemetry:
The prototypes confirmed the actions work uniformly across two languages
and SDK shapes; each consumer workflow ended up ~130 lines, of which only
~50 are project-specific (build, run, drive traffic).
Examples (follow-up)
Per discussion with @jsuereth, @lmolkova, and @jerbly, examples will be added
post-merge to the opentelemetry-weaver-examples
repo (consistent with how
setup-weaverexamples are hosted there today).A follow-up PR will add a
live_check_ci/example pinning these actions toa tagged weaver ref once this PR lands.