feat(renovate): add coverage check for Bazel http_archive deps by chouetz · Pull Request #50005 · DataDog/datadog-agent

chouetz · 2026-04-28T14:03:05Z

What does this PR do?

Adds a CI lint that fails any PR introducing or modifying an http_archive(...) block in deps/repos.MODULE.bazel without a corresponding customManager entry in renovate.json (or a deliberate allowlist exception).

Components:

tasks/renovate.py::check_bazel_coverage — invoke task that compares the set of http_archive(name=...) entries in deps/repos.MODULE.bazel against customManagers[].depNameTemplate in renovate.json, minus an explicit allowlist.
deps/.renovate-untracked.json — typed allowlist with mandatory non-empty rationale strings. Currently seeded with all 29 deps marked as "pending tracking in Phase 2x"; follow-up PRs will move each entry from this file into a customManager.
.github/workflows/validate-renovate-deps.yml — runs the task on PRs that touch deps/, renovate.json, or the task itself.

Motivation

Native C/C++ deps in deps/repos.MODULE.bazel (openssl, krb5, libxml2, sqlite3, ...) are pinned via http_archive(...). Renovate's built-in bazel-module manager only covers bazel_dep(...) declarations from the BCR registry, not http_archive calls inside module_extension blocks. As a result, none of the 29 native deps in this repo are tracked by Renovate today — they drift silently behind upstream.

Recent OpenSSL audit example: openssl is pinned at 3.5.6 in three places, but packaging/aix/stages/01-native-libs.sh:67 still says 3.5.5 and tasks/msi.py:96 says 3.5. Nothing surfaced this drift until manual review.

This PR alone doesn't add tracking — it adds the enforcement scaffold so that subsequent PRs that introduce customManagers for each dep can move entries out of the allowlist deliberately, and so that future contributors adding new http_archive blocks can't bypass tracking.

Describe how you validated your changes

dda inv -- renovate.check-bazel-coverage exits 0 with the seeded allowlist (29/29 covered).
Removed xz from the allowlist locally, re-ran: task exits 1 and emits the expected markdown report identifying xz as untracked. Restored, re-verified pass.
Workflow YAML mirrors the structure of cargo-bazel-tidy.yml and go-mod-tidy.yml (checkout → install-dda → run task), with a path filter limited to deps/**, renovate.json, and the task module itself.

Additional Notes

This is PR 1 of 5 in a multi-PR initiative to bring Renovate coverage to all 29 Bazel-pinned native deps. The remaining PRs are sequenced as:

Phase 1b — companion workflow that auto-refreshes Bazel sha256 on Renovate-bumped PRs (modeled on .github/workflows/cargo-bazel-tidy.yml + tasks/python_version.py::_prepare_bazel_update).
Phase 0 — small drift-cleanup PR bumping AIX/MSI openssl pins to 3.5.6.
Phase 2a/b/c — three batched customManager PRs (~14 / ~6 / ~3 deps each), grouped by datasource type. Each removes its deps from the allowlist as it adds them to renovate.json.

Phase-3 (5 hard deps requiring custom datasources: bzip2, attr, gpg-error, gcrypt, unixodbc, plus sqlite3's templated version) stays in the allowlist with explicit rationales until a follow-up effort adds custom datasources.

dd-octo-sts · 2026-04-28T14:37:17Z

Files inventory check summary

File checks results against ancestor 1f1f150e:

Results for datadog-agent_7.80.0~devel.git.707.47a550a.pipeline.112818027-1_amd64.deb:

No change detected

cit-pr-commenter-54b7da · 2026-04-28T15:01:35Z

Regression Detector

Regression Detector Results

Metrics dashboard
Target profiles
Run ID: cf5bf790-d972-471a-bfdd-faadf45c53a6

Baseline: d9f9915
Comparison: 0b494ab
Diff

❌ Experiments with retried target crashes

This is a critical error. One or more replicates failed with a non-zero exit code. These replicates may have been retried. See Replicate Execution Details for more information.

quality_gate_idle_all_features

Optimization Goals: ✅ No significant changes detected

Experiments ignored for regressions

Regressions in experiments with settings containing erratic: true are ignored.

perf	experiment	goal	Δ mean %	Δ mean % CI	trials	links
➖	docker_containers_cpu	% cpu utilization	+1.18	[-1.76, +4.11]	1	Logs

Fine details of change detection per experiment

perf	experiment	goal	Δ mean %	Δ mean % CI	trials	links
➖	docker_containers_cpu	% cpu utilization	+1.18	[-1.76, +4.11]	1	Logs
➖	otlp_ingest_logs	memory utilization	+0.77	[+0.67, +0.87]	1	Logs
➖	tcp_syslog_to_blackhole	ingress throughput	+0.33	[+0.14, +0.52]	1	Logs
➖	file_tree	memory utilization	+0.28	[+0.23, +0.33]	1	Logs
➖	ddot_metrics_sum_cumulative	memory utilization	+0.25	[+0.09, +0.41]	1	Logs
➖	quality_gate_logs	% cpu utilization	+0.04	[-0.94, +1.02]	1	Logs bounds checks dashboard
➖	file_to_blackhole_0ms_latency	egress throughput	+0.04	[-0.51, +0.59]	1	Logs
➖	file_to_blackhole_100ms_latency	egress throughput	+0.01	[-0.14, +0.15]	1	Logs
➖	tcp_dd_logs_filter_exclude	ingress throughput	-0.00	[-0.09, +0.08]	1	Logs
➖	uds_dogstatsd_to_api	ingress throughput	-0.00	[-0.21, +0.20]	1	Logs
➖	uds_dogstatsd_to_api_v3	ingress throughput	-0.01	[-0.21, +0.19]	1	Logs
➖	uds_dogstatsd_20mb_12k_contexts_20_senders	memory utilization	-0.02	[-0.07, +0.03]	1	Logs
➖	quality_gate_idle	memory utilization	-0.02	[-0.07, +0.02]	1	Logs bounds checks dashboard
➖	otlp_ingest_metrics	memory utilization	-0.03	[-0.19, +0.12]	1	Logs
➖	file_to_blackhole_1000ms_latency	egress throughput	-0.04	[-0.49, +0.40]	1	Logs
➖	file_to_blackhole_500ms_latency	egress throughput	-0.05	[-0.46, +0.36]	1	Logs
➖	ddot_metrics	memory utilization	-0.07	[-0.27, +0.12]	1	Logs
➖	ddot_metrics_sum_cumulativetodelta_exporter	memory utilization	-0.13	[-0.36, +0.11]	1	Logs
➖	ddot_logs	memory utilization	-0.14	[-0.23, -0.06]	1	Logs
➖	quality_gate_idle_all_features	memory utilization	-0.43	[-0.47, -0.38]	1	Logs bounds checks dashboard
➖	docker_containers_memory	memory utilization	-0.52	[-0.63, -0.42]	1	Logs
➖	quality_gate_metrics_logs	memory utilization	-0.54	[-0.79, -0.29]	1	Logs bounds checks dashboard
➖	ddot_metrics_sum_delta	memory utilization	-0.87	[-1.06, -0.69]	1	Logs

Bounds Checks: ✅ Passed

perf	experiment	bounds_check_name	replicates_passed	observed_value	links
✅	docker_containers_cpu	simple_check_run	10/10	695 ≥ 26
✅	docker_containers_memory	memory_usage	10/10	245.42MiB ≤ 370MiB
✅	docker_containers_memory	simple_check_run	10/10	714 ≥ 26
✅	file_to_blackhole_0ms_latency	memory_usage	10/10	0.16GiB ≤ 1.20GiB
✅	file_to_blackhole_0ms_latency	missed_bytes	10/10	0B = 0B
✅	file_to_blackhole_1000ms_latency	memory_usage	10/10	0.21GiB ≤ 1.20GiB
✅	file_to_blackhole_1000ms_latency	missed_bytes	10/10	0B = 0B
✅	file_to_blackhole_100ms_latency	memory_usage	10/10	0.17GiB ≤ 1.20GiB
✅	file_to_blackhole_100ms_latency	missed_bytes	10/10	0B = 0B
✅	file_to_blackhole_500ms_latency	memory_usage	10/10	0.19GiB ≤ 1.20GiB
✅	file_to_blackhole_500ms_latency	missed_bytes	10/10	0B = 0B
✅	quality_gate_idle	intake_connections	10/10	3 ≤ 4	bounds checks dashboard
✅	quality_gate_idle	memory_usage	10/10	141.62MiB ≤ 147MiB	bounds checks dashboard
✅	quality_gate_idle_all_features	intake_connections	10/10	3 ≤ 4	bounds checks dashboard
✅	quality_gate_idle_all_features	memory_usage	10/10	470.22MiB ≤ 495MiB	bounds checks dashboard
✅	quality_gate_logs	intake_connections	10/10	4 ≤ 6	bounds checks dashboard
✅	quality_gate_logs	memory_usage	10/10	179.08MiB ≤ 195MiB	bounds checks dashboard
✅	quality_gate_logs	missed_bytes	10/10	0B = 0B	bounds checks dashboard
✅	quality_gate_metrics_logs	cpu_usage	10/10	345.85 ≤ 2000	bounds checks dashboard
✅	quality_gate_metrics_logs	intake_connections	10/10	3 ≤ 6	bounds checks dashboard
✅	quality_gate_metrics_logs	memory_usage	10/10	379.39MiB ≤ 430MiB	bounds checks dashboard
✅	quality_gate_metrics_logs	missed_bytes	10/10	0B = 0B	bounds checks dashboard

Explanation

Confidence level: 90.00%
Effect size tolerance: |Δ mean %| ≥ 5.00%

Performance changes are noted in the perf column of each table:

✅ = significantly better comparison variant performance
❌ = significantly worse comparison variant performance
➖ = no significant change in performance

A regression test is an A/B test of target performance in a repeatable rig, where "performance" is measured as "comparison variant minus baseline variant" for an optimization goal (e.g., ingress throughput). Due to intrinsic variability in measuring that goal, we can only estimate its mean value for each experiment; we report uncertainty in that value as a 90.00% confidence interval denoted "Δ mean % CI".

For each experiment, we decide whether a change in performance is a "regression" -- a change worth investigating further -- if all of the following criteria are true:

Its estimated |Δ mean %| ≥ 5.00%, indicating the change is big enough to merit a closer look.
Its 90.00% confidence interval "Δ mean % CI" does not contain zero, indicating that if our statistical model is accurate, there is at least a 90.00% chance there is a difference in performance between baseline and comparison variants.
Its configuration does not mark it "erratic".

Replicate Execution Details

We run multiple replicates for each experiment/variant. However, we allow replicates to be automatically retried if there are any failures, up to 8 times, at which point the replicate is marked dead and we are unable to run analysis for the entire experiment. We call each of these attempts at running replicates a replicate execution. This section lists all replicate executions that failed due to the target crashing or being oom killed.

Note: In the below tables we bucket failures by experiment, variant, and failure type. For each of these buckets we list out the replicate indexes that failed with an annotation signifying how many times said replicate failed with the given failure mode. In the below example the baseline variant of the experiment named experiment_with_failures had two replicates that failed by oom kills. Replicate 0, which failed 8 executions, and replicate 1 which failed 6 executions, all with the same failure mode.

Experiment	Variant	Replicates	Failure	Logs	Debug Dashboard
experiment_with_failures	baseline	0 (x8) 1 (x6)	Oom killed		Debug Dashboard

The debug dashboard links will take you to a debugging dashboard specifically designed to investigate replicate execution failures.

❌ Retried Normal Replicate Execution Failures (non-profiling)

Experiment	Variant	Replicates	Failure	Debug Dashboard
quality_gate_idle_all_features	comparison	9	Oom killed	Debug Dashboard

CI Pass/Fail Decision

✅ Passed. All Quality Gates passed.

quality_gate_idle_all_features, bounds check intake_connections: 10/10 replicas passed. Gate passed.
quality_gate_idle_all_features, bounds check memory_usage: 10/10 replicas passed. Gate passed.
quality_gate_metrics_logs, bounds check intake_connections: 10/10 replicas passed. Gate passed.
quality_gate_metrics_logs, bounds check missed_bytes: 10/10 replicas passed. Gate passed.
quality_gate_metrics_logs, bounds check cpu_usage: 10/10 replicas passed. Gate passed.
quality_gate_metrics_logs, bounds check memory_usage: 10/10 replicas passed. Gate passed.
quality_gate_idle, bounds check intake_connections: 10/10 replicas passed. Gate passed.
quality_gate_idle, bounds check memory_usage: 10/10 replicas passed. Gate passed.
quality_gate_logs, bounds check missed_bytes: 10/10 replicas passed. Gate passed.
quality_gate_logs, bounds check intake_connections: 10/10 replicas passed. Gate passed.
quality_gate_logs, bounds check memory_usage: 10/10 replicas passed. Gate passed.

dd-octo-sts · 2026-04-28T16:19:28Z

Static quality checks

✅ Please find below the results from static quality gates
Comparison made with ancestor 1f1f150
📊 Static Quality Gates Dashboard
🔗 SQG Job

33 successful checks with minimal change (< 2 KiB)

	Quality gate	Current Size
✅	agent_deb_amd64	743.175 MiB
✅	agent_deb_amd64_fips	701.004 MiB
✅	agent_heroku_amd64	309.406 MiB
✅	agent_msi	608.441 MiB
✅	agent_rpm_amd64	743.158 MiB
✅	agent_rpm_amd64_fips	700.988 MiB
✅	agent_rpm_arm64	720.948 MiB
✅	agent_rpm_arm64_fips	681.908 MiB
✅	agent_suse_amd64	743.158 MiB
✅	agent_suse_amd64_fips	700.988 MiB
✅	agent_suse_arm64	720.948 MiB
✅	agent_suse_arm64_fips	681.908 MiB
✅	docker_agent_amd64	803.356 MiB
✅	docker_agent_arm64	805.987 MiB
✅	docker_agent_jmx_amd64	994.276 MiB
✅	docker_agent_jmx_arm64	985.685 MiB
✅	docker_cluster_agent_amd64	206.602 MiB
✅	docker_cluster_agent_arm64	220.637 MiB
✅	docker_cws_instrumentation_amd64	7.142 MiB
✅	docker_cws_instrumentation_arm64	6.689 MiB
✅	docker_host_profiler_amd64	302.210 MiB
✅	docker_host_profiler_arm64	313.686 MiB
✅	docker_dogstatsd_amd64	39.527 MiB
✅	docker_dogstatsd_arm64	37.753 MiB
✅	dogstatsd_deb_amd64	30.182 MiB
✅	dogstatsd_deb_arm64	28.308 MiB
✅	dogstatsd_rpm_amd64	30.182 MiB
✅	dogstatsd_suse_amd64	30.182 MiB
✅	iot_agent_deb_amd64	44.315 MiB
✅	iot_agent_deb_arm64	41.295 MiB
✅	iot_agent_deb_armhf	42.036 MiB
✅	iot_agent_rpm_amd64	44.315 MiB
✅	iot_agent_suse_amd64	44.315 MiB

) ### What does this PR do? Bumps `OPENSSL_VERSION` in `packaging/aix/stages/01-native-libs.sh` from `3.5.5` to `3.5.6` so the AIX native-libs build agrees with every other openssl pin in the repo. ### Motivation Recent audit surfaced that openssl is pinned in 5 places across the repo, with one source of drift: | File | Line | Version | Status | |---|---|---|---| | `deps/repos.MODULE.bazel` | 120 | 3.5.6 | ✅ | | `deps/openssl/version.bzl` | 1 | 3.5.6 | ✅ | | `omnibus/config/software/openssl3.rb` | 21 | 3.5.6 | ✅ | | `packaging/aix/stages/01-native-libs.sh` | 67 | **3.5.5** | ❌ drift | | `tasks/msi.py` | 96 | "3.5" (major.minor) | ✅ — intentional | The AIX file's own header (line 60) explicitly declares `# Source of truth: deps/repos.MODULE.bazel`, so the lag is unambiguously a missed sync, not an intentional pin. `tasks/msi.py:96` is left alone: `"3.5"` is the OpenSSL Windows registry-key segment (per `https://github.com/openssl/openssl/blob/master/NOTES-WINDOWS.md#installation-directories`) and is intentionally major.minor only — bumping to `"3.5.6"` would be wrong. The `3.5.x` line is still correct for openssl 3.5.6. This drift cleanup is also a precondition for adding Renovate tracking to the openssl dep (PR-A in the upcoming Bazel-native-deps batch). Renovate would otherwise see two distinct openssl versions in the repo and open conflicting PRs on every bump. ### Describe how you validated your changes - `git grep -nF 'openssl' packaging/aix/stages/01-native-libs.sh` confirms all references use the `$OPENSSL_VERSION` variable; no hardcoded `3.5.5` strings remain. - The AIX script downloads from `github.com/openssl/openssl/releases/download/openssl-${OPENSSL_VERSION}/openssl-${OPENSSL_VERSION}.tar.gz` (with `openssl.org/source` as fallback). Both URLs serve a valid 3.5.6 tarball today. - The script does NOT pin a sha256 — it trusts the upstream source. So no hash refresh is needed. ### Additional Notes - Same file also contains a **separate libxslt drift the other direction** (line 70: `LIBXSLT_VERSION="1.1.45"` while `deps/repos.MODULE.bazel:347` is at `1.1.43`). Out of scope for this PR — flagged for owner of the AIX build pipeline to triage. - Companion to #50005 (Renovate coverage check). Both ship before the upcoming Renovate-tracking PRs. Co-authored-by: pierre.gimalac <pierre.gimalac@datadoghq.com>

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c961836f36

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

JSGette · 2026-05-05T11:22:41Z

General notes:

I'd say the check should not only cover repos.MODULE.bazel but all *.MODULE.bazel files in order to detect http_archive usage.
In some cases http_file might be used as well, so at least it would be handy to check this too (or mark as a TODO)
I'd prefer to have this as a bazel runnable task (if not a test task) instead of dda inv -- renovate.check-bazel-coverage.

I approved prior to noticing Joseph's review, sorry.

KevinFairise2

Should we make that linter required? If we do not I guess it is not going to block anyone?

aiuto · 2026-05-05T16:32:08Z

We don't need rennovate to capture the C deps. They are slow moving targets where we expect to get the update from ADMS.

chouetz · 2026-05-05T16:45:38Z

Should we make that linter required? If we do not I guess it is not going to block anyone?

@KevinFairise2 yes that's a good suggestion, I'll update the config as soon as the test is merged

chouetz · 2026-05-07T12:13:46Z

@codex review

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 27cf77547b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chouetz · 2026-05-07T12:33:07Z

@codex review

chatgpt-codex-connector · 2026-05-07T12:36:30Z

Codex Review: Didn't find any major issues. What shall we delve into next?

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Adds a CI lint that fails any PR introducing or modifying an `http_archive(...)` block in `deps/repos.MODULE.bazel` without a corresponding `customManager` entry in `renovate.json`. Without this check, native deps (openssl, krb5, libxml2, …) drift silently behind upstream — Renovate's `bazel-module` manager only covers `bazel_dep(...)` declarations from the BCR registry, not the `http_archive(...)` calls used for natives. None of the 29 such deps in the repo are tracked today. Pieces: - `tasks/renovate.py::check_bazel_coverage` — invoke task that diffs the set of `http_archive(name=...)` entries in the bazel module file against `customManagers[].depNameTemplate` in `renovate.json`, minus an explicit allowlist. Writes a markdown report to `$GITHUB_STEP_SUMMARY` on failure. - `deps/.renovate-untracked.json` — typed allowlist with non-empty rationale strings. Currently lists all 29 deps as pending tracking; follow-up PRs will move each entry from this file into a customManager in `renovate.json`. - `.github/workflows/validate-renovate-deps.yml` — runs the task on PRs touching `deps/`, `renovate.json`, or the task itself. Run locally with `dda inv -- renovate.check-bazel-coverage`. fix(renovate): replace regex with block parser for http_archive names The previous regex required `name` to be the first argument after the opening paren, silently skipping archives where a comment or another keyword preceded it. The new parser tracks parenthesis depth and string boundaries, then searches for `name = "..."` anywhere within each block. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> fix(renovate): scan all *.MODULE.bazel files in deps/, not just repos.MODULE.bazel Previously only deps/repos.MODULE.bazel was scanned, so http_archive calls in per-dep MODULE.bazel files (e.g. deps/cpython/, deps/curl/) were invisible to the coverage check. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> fix(renovate): extend coverage check to http_file in addition to http_archive deps/repos.MODULE.bazel already uses http_file (e.g. sqlite3_license, cacerts). These were invisible to the check because only http_archive was parsed. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> feat(renovate): add bazel run //tasks:check_renovate_bazel_coverage target Adds a py_binary so the coverage check can be invoked via Bazel without needing dda/invoke. BUILD_WORKSPACE_DIRECTORY (set by `bazel run`) is used to locate the repo root; direct `python tasks/renovate.py` invocation falls back to the file's parent path. Updates the validate-renovate-deps.yml workflow to use the new Bazel target via the existing bazel-cache action, removing the dda dependency from that workflow. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> code review

Adds a CI lint that fails any PR introducing or modifying an `http_archive(...)` block in `deps/repos.MODULE.bazel` without a corresponding `customManager` entry in `renovate.json` (or a deliberate allowlist exception). Components: - `tasks/renovate.py::check_bazel_coverage` — invoke task that compares the set of `http_archive(name=...)` entries in `deps/repos.MODULE.bazel` against `customManagers[].depNameTemplate` in `renovate.json`, minus an explicit allowlist. - `deps/.renovate-untracked.json` — typed allowlist with mandatory non-empty rationale strings. Currently seeded with all 29 deps marked as "pending tracking in Phase 2x"; follow-up PRs will move each entry from this file into a `customManager`. - `.github/workflows/validate-renovate-deps.yml` — runs the task on PRs that touch `deps/`, `renovate.json`, or the task itself. Native C/C++ deps in `deps/repos.MODULE.bazel` (openssl, krb5, libxml2, sqlite3, ...) are pinned via `http_archive(...)`. Renovate's built-in `bazel-module` manager only covers `bazel_dep(...)` declarations from the BCR registry, **not** `http_archive` calls inside `module_extension` blocks. As a result, **none of the 29 native deps in this repo are tracked by Renovate today** — they drift silently behind upstream. Recent OpenSSL audit example: openssl is pinned at 3.5.6 in three places, but `packaging/aix/stages/01-native-libs.sh:67` still says 3.5.5 and `tasks/msi.py:96` says 3.5. Nothing surfaced this drift until manual review. This PR alone doesn't add tracking — it adds the **enforcement scaffold** so that subsequent PRs that introduce `customManagers` for each dep can move entries out of the allowlist deliberately, and so that future contributors adding new `http_archive` blocks can't bypass tracking. - `dda inv -- renovate.check-bazel-coverage` exits 0 with the seeded allowlist (29/29 covered). - Removed `xz` from the allowlist locally, re-ran: task exits 1 and emits the expected markdown report identifying `xz` as untracked. Restored, re-verified pass. - Workflow YAML mirrors the structure of `cargo-bazel-tidy.yml` and `go-mod-tidy.yml` (checkout → install-dda → run task), with a path filter limited to `deps/**`, `renovate.json`, and the task module itself. This is **PR 1 of 5** in a multi-PR initiative to bring Renovate coverage to all 29 Bazel-pinned native deps. The remaining PRs are sequenced as: - Phase 1b — companion workflow that auto-refreshes Bazel `sha256` on Renovate-bumped PRs (modeled on `.github/workflows/cargo-bazel-tidy.yml` + `tasks/python_version.py::_prepare_bazel_update`). - Phase 0 — small drift-cleanup PR bumping AIX/MSI openssl pins to 3.5.6. - Phase 2a/b/c — three batched `customManager` PRs (~14 / ~6 / ~3 deps each), grouped by datasource type. Each removes its deps from the allowlist as it adds them to `renovate.json`. Phase-3 (5 hard deps requiring custom datasources: bzip2, attr, gpg-error, gcrypt, unixodbc, plus sqlite3's templated version) stays in the allowlist with explicit rationales until a follow-up effort adds custom datasources.

### What does this PR do? Adds a CI companion workflow that auto-refreshes the `sha256` field of any `http_archive(...)` block in `deps/repos.MODULE.bazel` whose version literal was changed by Renovate. Without it, every Renovate-generated bump PR for native deps fails Bazel CI immediately because Renovate updates `strip_prefix` and `urls` but cannot recompute the hash. Three pieces: - `tasks/bazel.py::refresh_archive_hashes` — invoke task that diffs `deps/repos.MODULE.bazel` against a base ref, identifies blocks whose non-sha256 fields changed, downloads the new tarball from the first reachable URL in `urls = [...]`, computes the sha256, and rewrites the source line. Block-scoped substitutions and strict match-count validation prevent silent partial edits. URL string literals are filtered so computed expressions (e.g. sqlite3's `.format(...)`) are skipped gracefully. - `.github/workflows/bazel-native-tidy.yml` — runs the task on Renovate PRs labeled `dependencies-bazel-native`, then commits and force-pushes via `dd-octo-sts` + `chouetz/push-signed-commits`. Mirrors the structure of `.github/workflows/cargo-bazel-tidy.yml` and `.github/workflows/go-mod-tidy.yml`. - `.github/chainguard/self.bazel-native-tidy.push-branch.sts.yaml` — dd-octo-sts policy granting `contents: write` to the workflow's job-workflow-ref. Identical shape to `self.cargo-bazel-tidy.push-branch.sts.yaml`. ### Motivation https://datadoghq.atlassian.net/browse/ACIX-1493 This is a precondition for the upcoming Renovate-tracking PRs that add `customManagers` for the 29 native deps in `deps/repos.MODULE.bazel`. Renovate's regex managers can update version literals but never the sha256 (no native Bazel command does this either — `bazel mod tidy` only refreshes `MODULE.bazel.lock`, not the inline `sha256 = "..."` strings). Without this companion, **every** Renovate-bumped PR for natives would land with a broken Bazel build and need manual intervention. The repo already has the same shape for cpython (`tasks/python_version.py::_prepare_bazel_update`) — this generalizes that approach so it applies to any `http_archive` block driven by Renovate. ### Describe how you validated your changes - `dda inv -- bazel.refresh-archive-hashes --base-ref=origin/main` is a no-op on a clean branch (no http_archive blocks differ from main). - Simulated a Renovate-style bump locally: rewrote `zlib-1.3.1` → `zlib-1.3` (a real older release) in `deps/repos.MODULE.bazel` while leaving the sha256 stale. Ran `dda inv -- bazel.refresh-archive-hashes --base-ref=HEAD`. The task: - detected exactly the `zlib` block as changed, - tried the S3 mirror URL first (404, expected — Datadog's mirror won't have a new version yet), - fell through to GitHub's release URL, - downloaded, hashed (`ff0ba4c292013dbc...`, matches zlib 1.3 upstream), - rewrote only the sha256 line with no collateral whitespace/blank-line changes. - Reverted the test, working tree clean. Verified the diff was scoped: 1 block, 4 lines (sha256, strip_prefix, 2 URLs). ### Additional Notes - The workflow gate (`renovate[bot]` user + `dependencies-bazel-native` label) follows the existing `cargo-bazel-tidy.yml` and `go-mod-tidy.yml` patterns. The `dependencies-bazel-native` label will be applied automatically by Renovate via a packageRule added in the upcoming Phase 2a/b/c tracking PRs. - S3 mirror fallback is unaffected: when Renovate bumps a version, the new tarball isn't yet on `dd-agent-omnibus.s3.amazonaws.com`, but Bazel's `http_archive` tries `urls` in order, so a 404 on S3 falls through cleanly to upstream. No mirror-push is added in this PR; that can be a separate follow-up if desired. - New `http_archive` blocks added in a PR (i.e. not present in the base ref) are deliberately NOT auto-hashed — initial sha256 is the human's job, since the base reviewer needs to verify the upstream source. - Companion to #50005 (validation workflow) and #50022 (openssl drift cleanup). All three should land before the Phase 2 tracking PRs. Co-authored-by: nicolas.schweitzer <nicolas.schweitzer@datadoghq.com>

chouetz added changelog/no-changelog No changelog entry needed qa/no-code-change No code change in Agent code requiring validation team/agent-delivery labels Apr 28, 2026

dd-octo-sts Bot added the internal Identify a non-fork PR label Apr 28, 2026

github-actions Bot added the medium review PR review might take time label Apr 28, 2026

dd-octo-sts Bot added team/agent-devx team/agent-build labels Apr 28, 2026

This was referenced Apr 28, 2026

fix(aix): bump openssl to 3.5.6 to match deps/repos.MODULE.bazel #50022

Merged

feat(bazel): auto-refresh http_archive sha256 on Renovate PRs #50030

Merged

chouetz force-pushed the nicolas.schweitzer/renovate-deps-validator branch from a1ffab2 to c961836 Compare May 4, 2026 13:44

chouetz marked this pull request as ready for review May 5, 2026 11:11

chouetz requested review from a team as code owners May 5, 2026 11:11

chatgpt-codex-connector Bot reviewed May 5, 2026

View reviewed changes

Comment thread tasks/renovate.py Outdated

rdesgroppes previously approved these changes May 5, 2026

View reviewed changes

KevinFairise2 approved these changes May 5, 2026

View reviewed changes

chouetz force-pushed the nicolas.schweitzer/renovate-deps-validator branch from 4c61420 to 27cf775 Compare May 7, 2026 10:45

chatgpt-codex-connector Bot reviewed May 7, 2026

View reviewed changes

Comment thread tasks/renovate.py Outdated

Comment thread tasks/renovate.py Outdated

JSGette reviewed May 7, 2026

View reviewed changes

Comment thread tasks/renovate.py Outdated

JSGette reviewed May 7, 2026

View reviewed changes

Comment thread tasks/renovate.py Outdated

rdesgroppes reviewed May 8, 2026

View reviewed changes

Comment thread tasks/BUILD.bazel

github-actions Bot added long review PR is complex, plan time to review it and removed medium review PR review might take time labels May 8, 2026

rdesgroppes reviewed May 8, 2026

View reviewed changes

Comment thread tasks/renovate.py

This comment has been minimized.

Sign in to view

chouetz force-pushed the nicolas.schweitzer/renovate-deps-validator branch from 6eadaf6 to d3b8c10 Compare May 12, 2026 15:47

chouetz force-pushed the nicolas.schweitzer/renovate-deps-validator branch from d3b8c10 to 47a550a Compare May 12, 2026 19:57

chouetz merged commit 0b494ab into main May 13, 2026
262 of 263 checks passed

chouetz deleted the nicolas.schweitzer/renovate-deps-validator branch May 13, 2026 06:26

github-actions Bot added this to the 7.80.0 milestone May 13, 2026

Uh oh!

Conversation

chouetz commented Apr 28, 2026

What does this PR do?

Motivation

Describe how you validated your changes

Additional Notes

Uh oh!

dd-octo-sts Bot commented Apr 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Files inventory check summary

Results for datadog-agent_7.80.0~devel.git.707.47a550a.pipeline.112818027-1_amd64.deb:

Uh oh!

cit-pr-commenter-54b7da Bot commented Apr 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Regression Detector

Regression Detector Results

❌ Experiments with retried target crashes

Optimization Goals: ✅ No significant changes detected

Experiments ignored for regressions

Fine details of change detection per experiment

Bounds Checks: ✅ Passed

Explanation

Replicate Execution Details

❌ Retried Normal Replicate Execution Failures (non-profiling)

CI Pass/Fail Decision

Uh oh!

dd-octo-sts Bot commented Apr 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Static quality checks

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

JSGette commented May 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

KevinFairise2 left a comment

Choose a reason for hiding this comment

Uh oh!

aiuto commented May 5, 2026

Uh oh!

chouetz commented May 5, 2026

Uh oh!

chouetz commented May 7, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

Uh oh!

chouetz commented May 7, 2026

Uh oh!

chatgpt-codex-connector Bot commented May 7, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This comment has been minimized.

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

dd-octo-sts Bot commented Apr 28, 2026 •

edited

Loading

cit-pr-commenter-54b7da Bot commented Apr 28, 2026 •

edited

Loading

dd-octo-sts Bot commented Apr 28, 2026 •

edited

Loading

JSGette commented May 5, 2026 •

edited

Loading