Skip to content

chore(deps): bump opentelemetry stack 0.31 → 0.32#13

Open
Cliftonz wants to merge 5 commits into
mainfrom
chore/otel-0.32-bundle
Open

chore(deps): bump opentelemetry stack 0.31 → 0.32#13
Cliftonz wants to merge 5 commits into
mainfrom
chore/otel-0.32-bundle

Conversation

@Cliftonz
Copy link
Copy Markdown
Contributor

Summary

Coordinated bundle of the four interlocking OTEL crates that ship on a single release cadence and cannot be updated piecemeal:

  • opentelemetry 0.31 → 0.32
  • opentelemetry_sdk 0.31 → 0.32
  • opentelemetry-otlp 0.31 → 0.32
  • opentelemetry-appender-tracing 0.31 → 0.32

Supersedes #7, #8, #9, #10 — each of those bumps a single crate, which would fail to compile against the rest of the stack at 0.31.

Validation

  • cargo build clean (debug + release)
  • cargo clippy --all-features -- -D warnings clean
  • 997 tests passing (cargo test --lib --bins)
  • 0.32 is API-compatible with our usage of SdkLoggerProvider, SdkMeterProvider, BatchLogProcessor, PeriodicReader, and the OTLP HTTP exporter — no source changes required.
  • The recently-fixed resolve_otlp_endpoint / with_endpoint full-URL pipeline (commit 0c6538c) continues to work; 0.32 did not revisit that contract.

Test plan

  • cargo build
  • cargo clippy --all-features -- -D warnings
  • cargo test --lib --bins
  • CI green on this PR

Closes #7
Closes #8
Closes #9
Closes #10

🤖 Generated with Claude Code

Cliftonz and others added 2 commits May 25, 2026 22:22
Coordinated bundle of the four interlocking OTEL crates that ship
on a single release cadence and cannot be updated piecemeal:

- opentelemetry              0.31 → 0.32
- opentelemetry_sdk          0.31 → 0.32
- opentelemetry-otlp         0.31 → 0.32
- opentelemetry-appender-tracing 0.31 → 0.32

Supersedes dependabot PRs #7, #8, #9, #10 — each of those bumps
a single crate, which would fail to compile against the rest of
the stack at 0.31. Closing them after this lands.

Build clean (cargo build, cargo clippy --all-features -D warnings),
997 tests passing. The 0.32 release is API-compatible with our
usage of SdkLoggerProvider, SdkMeterProvider, BatchLogProcessor,
PeriodicReader, and the OTLP HTTP exporter — no source changes
were required. The recently-fixed resolve_otlp_endpoint /
with_endpoint full-URL pipeline (commit 0c6538c) continues to
work; the 0.32 release did not revisit that contract.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Cliftonz added a commit that referenced this pull request May 26, 2026
All four docs-quality.yml checks were failing on every PR before
any of the in-flight PRs even touched the surface. They surfaced
when PR #13 / #14 / #15 ran and exposed main's state to scrutiny.

Spell check (codespell):
  Add three entries to .codespellignore.
  - `dokcer` — intentional typo example in docs/adding-tools.md
    and docs/llms-full.txt demonstrating the fuzzy-suggest feature
    catching `dokcer` → `docker`. Without the ignore, every PR
    that touches those docs fails the spell check on a string
    that is supposed to be a typo.
  - `iterm` — proper noun for the iTerm2 macOS terminal app, used
    in docs/adding-tools.md.
  - `unparseable` — alternative spelling of `unparsable` used in
    docs/release-quirks-jarvy.md (pre-existing).

Link check (lychee):
  `exclude_mail` was removed in lychee 0.22 — the inverse
  `include_mail` now controls this behavior. Default is to skip
  mailtos, so the directive becomes `include_mail = false` to
  preserve the prior behavior. Without the fix lychee errors at
  config parse time with exit code 3 and never checks any links.

README ↔ values.schema invariants:
  The grep -F "^https://" invariant test was looking for the
  literal string `^https://` in the helm chart README. The schema
  pattern uses `^(|https://...)$` which contains `(|https` between
  the `^` and the `https`, so the substring match failed. Added a
  prose mention "URL must start with `^https://`" inside the
  endpoint-pattern bullet so the invariant has the literal substring
  to find without changing the schema or the human-readable
  description.

Vale prose lint:
  `vale-action@v2` periodically fails at `loadStyles` with
  `E100 Runtime error` and exits 2 before any docs are checked.
  The linter's content findings are already advisory via
  `fail_on_error: false`; add `continue-on-error: true` at the
  step level so the workflow doesn't block on an infra hiccup in
  the vendored vale toolchain. Real findings still surface via
  reviewdog annotations when loadStyles succeeds.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant