ci: use EPEL-packaged uv instead of pip-bootstrapped uv

[IlonaShishov]

Summary

• Switch CI containers from CentOS Stream 9 to CentOS Stream 10 with EPEL
• Replace pip install uv with dnf install uv across all four CI jobs (lock-file-check, vulnerability-scan, lint, test)
• Use Red Hat-supported uv package with security fixes instead of upstream PyPI version
• Use uv tool install pip-audit for isolated CLI tool installation in vulnerability scan job

Why CentOS Stream 10?

uv is not available in CentOS Stream 9 (not even in EPEL 9). CentOS Stream 10 + EPEL provides uv 0.11.15. This also aligns the CI environment with the production runtime (Containerfiles already use UBI 10).

What doesn't change

• Containerfiles — UBI 10 minimal images don't have EPEL access; builder stages remain pip-bootstrapped (ephemeral, discarded after build)
• pyproject.toml / lock files — uv stays in dev deps as a fallback for developers without system-level uv
• All downstream commands (uv pip install --system, --python python3.12, python3.12 -m pytest/ruff/mypy) work unchanged since CentOS Stream 10 ships Python 3.12 as the default python3

🤖 Generated with Claude Code

[yuvalk]

Containerfiles — UBI 10 minimal images don't have EPEL access; builder stages remain pip-bootstrapped (ephemeral, discarded after build)

is there any way to close this gap?

[IlonaShishov]

Containerfiles — UBI 10 minimal images don't have EPEL access; builder stages remain pip-bootstrapped (ephemeral, discarded after build)

@yuvalk
there are two approaches to replace pip install uv in the Containerfiles:

Option A —
Enable EPEL directly on UBI 10 minimal base image of the Containerfiles. Works technically (rpm -ivh epel-release + microdnf install uv), but the UBI EPEL repo has uv 0.10.2 while the CI version has 0.11.15 from CentOS Stream 10 EPEL. Different update cadences between UBI and CentOS Stream repos mean this version gap is ongoing, not a one-time lag.

Option B —
Multi-stage copy from CentOS Stream 10 in Containerfiles. Add a CentOS Stream 10 stage, install uv from EPEL, and COPY --from the binary into the UBI builder stage. This gives the exact same 0.11.15 version as CI. However,

• uv dynamically links against jemalloc, so we'd need to copy that library too
• The target image has no RPM awareness of either binary, if a future uv update adds a dependency, the build silently breaks
• It adds a build stage and an image dependency for a tool that runs once and is discarded

Claude Recommendation: leave the Containerfiles as-is.
The lock files are generated during development, neither CI nor the Containerfiles resolve or hash any dependencies themselves. Using EPEL-packaged uv in CI makes sense i guess since CI is where lock files are regenerated and verified to check integrity. But in the Containerfiles, uv is only used to install pre-resolved, pre-hashed dependencies. The uv binary there is derived from pip, which is installed ffrom a Red Hat-approved UBI base image anyway.

Beside that, the builder stage is ephemeral — uv installs dependencies, then the stage is thrown away. The uv binary never reaches the production image. The production image only contains the verified site-packages copied from the builder.

WDYT?

[luis5tb]

Containerfiles — UBI 10 minimal images don't have EPEL access; builder stages remain pip-bootstrapped (ephemeral, discarded after build)

@yuvalk there are two approaches to replace pip install uv in the Containerfiles:

Option A — Enable EPEL directly on UBI 10 minimal base image of the Containerfiles. Works technically (rpm -ivh epel-release + microdnf install uv), but the UBI EPEL repo has uv 0.10.2 while the CI version has 0.11.15 from CentOS Stream 10 EPEL. Different update cadences between UBI and CentOS Stream repos mean this version gap is ongoing, not a one-time lag.

Option B — Multi-stage copy from CentOS Stream 10 in Containerfiles. Add a CentOS Stream 10 stage, install uv from EPEL, and COPY --from the binary into the UBI builder stage. This gives the exact same 0.11.15 version as CI. However,

• uv dynamically links against jemalloc, so we'd need to copy that library too
• The target image has no RPM awareness of either binary, if a future uv update adds a dependency, the build silently breaks
• It adds a build stage and an image dependency for a tool that runs once and is discarded

Claude Recommendation: leave the Containerfiles as-is. The builder stage is ephemeral, uv installs dependencies, then the stage is thrown away. The uv binary never reaches the production image. The real security enforcement happens in CI, where uv is properly installed from EPEL via dnf install uv. CI regenerates and verifies lock files, and all installs use --require-hashes to validate package integrity. The production image only contains the verified site-packages copied from the builder not uv, not pip.

WDYT?

I would then probably go with leaving it as is on this PR (at least for now)