• Remove build-only packages pulling kernel headers to cut CVE noise in agent-tools.
• Make clean-train tool versions workflow-driven while keeping legacy pins unchanged.
• Build both arches on PRs (no push) to catch arm64-only mismatches pre-merge.

graph TD
  WF["agent-tools-build.yml"] --> ARGS["Clean train args"] --> BLD["Buildx (amd64/arm64)"] --> IMG["agent-tools images"] --> GATE["License+provenance gates"] -->|"push (publish only)"| HUB{{"Docker Hub"}}
  DF["Dockerfile.tools"] --> BLD

The following are alternative approaches to this PR:

1. Move clean-train version pins to a repo file (e.g., versions.env)

• ➕ Single source of truth usable by CI and local builds without copying build-args
• ➕ Easier for Renovate/custom tooling to bump versions via file-based updates
• ➖ Adds another config artifact to keep in sync with Dockerfile ARG names
• ➖ Requires small workflow refactor to read/parse the file reliably

2. Adopt docker-bake with named targets for legacy/clean

• ➕ More explicit train separation and reusable build definitions (local + CI)
• ➕ Cleaner multi-arch matrix handling and build-arg reuse
• ➖ Higher conceptual overhead for contributors unfamiliar with bake
• ➖ May require broader changes across existing Docker build workflows

Recommendation: The PR’s approach is solid for DEP-91: it keeps legacy pins stable in the Dockerfile while letting clean-train versions move quickly via workflow build-args, and it removes kernel-header sources at the root. If version bumps become frequent, consider extracting clean-train pins into a dedicated versions file to reduce workflow churn and improve local reproducibility.

Other (2) +64 / -40

agent-tools-build.ymlCentralize clean-train build args and smoke-build arm64 on PRs +26/-12

Centralize clean-train build args and smoke-build arm64 on PRs

• Adds a workflow output containing all clean-train tool version build-args (and disables legacy mongo for clean). Removes per-job include_legacy_mongo plumbing and makes arm64 builds run on PRs as no-push smoke tests, gating login/push steps on publish runs.

.github/workflows/agent-tools-build.yml

Dockerfile.toolsDrop kernel-header-inducing packages and make key tool pins ARG-driven +38/-28

Drop kernel-header-inducing packages and make key tool pins ARG-driven

• Removes build-only packages (python3-dev/alien/elfutils/libelf-dev) that pulled linux-libc-dev, and installs groff + python3-pip with --no-install-recommends while declaring xz-utils explicitly. Converts kubectl/sqlcmd/mongosh/mongodb-tools versions to ARGs and swaps unixodbc-dev for runtime unixodbc; also confines focal-security/libssl1.1 setup to the legacy-mongo guard.

Dockerfile.tools

Description

This PR drops build headers (python3-dev, unixodbc-dev) from hoophq/agent-tools, which is the base
image for hoophq/hoopdev; hoophq/infra’s hoopdev-dck Dockerfile installs native Python deps (e.g.,
pyodbc, pymssql) and may fail to build when infra upgrades its pinned hoopdev tag if any dependency
falls back to an sdist build (especially on non-amd64). Coordinate with infra to add explicit build
deps there or guarantee wheels-only installs.

Code

Dockerfile.tools[R167-169]

+    # DEP-91: runtime unixodbc (libodbc2 + isql), not the -dev headers which
+    # pull linux-libc-dev. Same source version; ODBC runtime preserved.
+    unixodbc=2.3.12-1ubuntu0.24.04.1 \

Relevance

●● Moderate

Cross-repo downstream build-risk; plausible but outside this PR’s scope. Team may note/coordinate,
not revert.

PR-#1595 PR-#1629

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR repo shows hoopdev is built FROM agent-tools and that agent-tools no longer includes python3-dev
and unixodbc-dev; infra repo shows a derived image that pip-installs native-extension packages which
may require those headers if wheels aren’t available.

Dockerfile.dev[1-7] Dockerfile.tools[26-64] Dockerfile.tools[163-176] External repo: hoophq/infra, dock/Dockerfile [1-55]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`hoophq/infra` builds `hoophq/hoopdev-dck` FROM `hoophq/hoopdev`, and `hoophq/hoopdev` is built FROM `hoophq/agent-tools`. This PR removes `python3-dev` and switches from `unixodbc-dev` to `unixodbc` in `agent-tools` (intentionally, to drop kernel headers CVEs). If infra’s `pip3.12 install ... pyodbc/pymssql/...` ever falls back to source builds (wheel gaps, platform differences), the build can fail due to missing Python/ODBC headers.

### Issue Context
- The infra Docker build currently pins `FROM hoophq/hoopdev:1.54.0`; it won’t break immediately, but it can break on the next bump to a hoopdev version built on the new `agent-tools` base.
- This is most likely to surface on architectures where wheels are missing or if dependency versions change.

### Fix Focus Areas
- Dockerfile.tools[26-64]
- Dockerfile.tools[163-176]
- Dockerfile.dev[1-7]
- /cross_repos/infra/dock/Dockerfile[1-55]

### Suggested remediation options
1) In **hoophq/infra** `dock/Dockerfile`, add explicit build deps for the pip layer (only if needed): `python3-dev`, `build-essential`, and `unixodbc-dev` (or pin/ensure wheel-only installs).
2) Alternatively, keep `agent-tools` slim but document this as a breaking contract for downstream images and add a CI build of infra’s Dockerfile against a hoopdev tag built from the new base (coordination/test gate).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

💡 Did you know, you can enable the Remediation agent and Qodo fixes findings in a dedicated fix PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗