chore(deps): lock file maintenance (release-v2.10)

[renovate-sh-app]

This PR contains the following updates:

Update	Change
lockFileMaintenance	All locks refreshed

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

🔧 This Pull Request updates lock files to use the latest dependency versions.

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • Between 12:00 AM and 03:59 AM, only on Monday (* 0-3 * * 1)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

• If you want to rebase/retry this PR, check this box

---

Need help?

You can ask for more help in the following Slack channel: #proj-renovate-self-hosted. In that channel you can also find ADR and FAQ docs in the Resources section.

[tempo-ci-app]

Diagnosis

The only failing check is Run Unit Tests (test-with-cover-tempodb), failing on:

--- FAIL: TestTimeWindowBlockSelectorBlocksToCompact/doesn't_select_blocks_in_last_active_window (0.01s)
    compaction_block_selector_test.go:937

The test sets up blocks with EndTime: now.Add(-activeWindowDuration) (24h ago) using a now captured at test-file init time (compaction_block_selector_test.go:14, now := time.Now()). Inside NewTimeWindowBlockSelector, a fresh time.Now() is captured and used to compute the activeWindow boundary. windowForTime truncates with second granularity (MaxCompactionRange = time.Second), so the test only passes when both time.Now() calls fall in the same Unix second. When the second boundary is crossed between test setup and the constructor call, the boundary block is no longer classified as falling in the active window, gets selected for compaction, and the assertion fails. The CI log shows exactly this: expected empty blocklist, got the two boundary blocks; expected hash "", got -1780442596-0.

This is a pre-existing flake in compaction_block_selector_test.go, not caused by this PR. The test passed 20/20 runs locally. The file/test no longer exists on main (removed by #6273 "Tempo 3.0: Remove compactor and v2 block encoding code"), so a stabilization fix would be a release-v2.10-only test change.

Why no fix

The PR is a Renovate lock file maintenance change touching only jsonnet artifacts:

• example/tk/jsonnetfile.lock.json
• operations/jsonnet-compiled/jsonnetfile.lock.json
• operations/jsonnet/enterprise/jsonnetfile.lock.json
• operations/jsonnet/microservices/jsonnetfile.lock.json
• operations/tempo-mixin/jsonnetfile.lock.json
• example/tk/vendor/github.com/grafana/jsonnet-libs/prometheus/prometheus.libsonnet
• {example/tk,operations/jsonnet-compiled}/vendor/github.com/jsonnet-libs/k8s-libsonnet/1.32/_custom/{autoscaling,core}.libsonnet

No Go code, no go.mod/go.sum, no Makefile, no test setup. The Go test failure cannot have been caused by these changes. Fixing the flaky time-boundary test is out of scope for this PR.

Recommendation

Retry the failing job — it should pass on re-run. If the test keeps flaking on release-v2.10, open a separate PR to stabilize TestTimeWindowBlockSelectorBlocksToCompact (e.g. move EndTime further from the boundary, or inject a fixed now).

🤖 fix-renovate-prs: no_fix

[tempo-ci-app]

Re-running flaky test

Check: Run Unit Tests (test-with-cover-tempodb)

Why this is a flake, not a real failure:

This PR only modifies jsonnet lock files and libsonnet files — no Go code is touched, so it cannot have broken a Go unit test. The single failing assertion is in TestTimeWindowBlockSelectorBlocksToCompact/doesn't_select_blocks_in_last_active_window, which has a timing race:

• compaction_block_selector_test.go:14 captures now := time.Now() once at the start of the test function.
• compaction_block_selector.go:61 calls time.Now() again inside NewTimeWindowBlockSelector, executed per-subtest.
• The test passes time.Second as MaxCompactionRange, so windowForTime divides the timestamp by 1 second.
• The "active-window cut-over" guard w == activeWindow (compaction_block_selector.go:86) only triggers when both time.Now() calls fall in the same Unix second.

If any delay crosses a second boundary (plausible given the long-running tempodb test package), the block lands in the "outside active window" branch instead of being excluded, which exactly matches the observed actual hash -1780442596-0 (format tenantID-window-replicationFactor from compaction_block_selector.go:117).

Action: re-running Run Unit Tests (test-with-cover-tempodb) — the race is unlikely to repeat on rerun. Fixing the underlying flake is out of scope for a lock-file-maintenance PR on release-v2.10.

🤖 fix-renovate-prs: rerun_failed_actions