kai_mcp_solution_server: hash-locked requirements for Hermeto permissive mode

[fabianvf]

Regenerates kai_mcp_solution_server/requirements.txt with --generate-hashes and adds requirements-build.txt for Hermeto's pip backend, so ART can exercise the new permissive-mode support (openshift-eng/art-tools#3047) against the solution-server. Resolves the mta-solution-server side of KONFLUX-14150.

What's in the overlay

File	Change	Why
kai_mcp_solution_server/requirements.txt	regenerated with uv pip compile --generate-hashes (192 → 3766 lines)	Hermeto requires hashes
kai_mcp_solution_server/requirements-build.txt	new, generated by pybuild-deps compile --generate-hashes (1045 lines, 65 build deps)	Hermeto pip backend resolves build deps from this file
kai_mcp_solution_server/requirements-build-constraints.txt	new	Pins meson==1.9.2 — meson >=1.10 ships wheels only and pybuild-deps can't introspect wheels
scripts/post-sync.sh	new, regen entrypoint	One command (./scripts/post-sync.sh) regenerates both files. Invoked by Dylan's mta-sync post-sync hook AND by the CI verify workflow
.gitattributes	merge=ours for requirements.txt and the verify workflow	Upstream konveyor/kai's unhashed copies won't fight the merge
.github/workflows/verify-requirements-txt.yml	rewritten to call ./scripts/post-sync.sh + diff	Drift detector for direct PRs; first-sync backstop
konflux.solution-server.Dockerfile	uncomment + path-fix the requirements-build.txt COPY	Wire the new file into the Konflux build

Note: deliberately did NOT add a make target — kai_mcp_solution_server/Makefile is shared with upstream konveyor/kai, and a midstream-only target there pollutes their make help output and adds merge-attack-surface. All regen logic lives in scripts/post-sync.sh (which is a net-new file invisible to upstream merges).

How this stays in sync with konveyor/kai upstream

Dylan's dymurray/mta-sync does git merge konveyor/kai → migtools/mta-kai. Upstream keeps the unhashed requirements.txt (their verify-requirements-txt.yml regenerates it via uv pip freeze — a fine fit for an unhashed convenience export, but incompatible with Hermeto). The two-piece overlay handles this without manual merge work:

1. .gitattributes merge=ours keeps midstream's hashed requirements.txt (and our verify workflow) untouched on git merge.
2. scripts/post-sync.sh runs after each successful sync via a new hook in mta-sync, regenerating requirements.txt + requirements-build.txt from the newly-merged pyproject.toml so dep bumps propagate. No drift.

The verify-requirements-txt.yml workflow's regen-and-diff is the safety net — if anyone bumps deps on this fork directly and forgets to regen, CI fails with the exact command to run.

Merge-conflict / drift caveats

requirements.txt: merge=ours + scripts/post-sync.sh keep it both conflict-free AND in-step with upstream's pyproject.toml changes. No drift.

verify-requirements-txt.yml: merge=ours keeps it conflict-free, but it WILL slowly drift from upstream's copy — e.g. if konveyor bumps actions/setup-python@v5 → @v6, we won't auto-pick it up. That's acceptable because the two workflows are doing different things (upstream's verifies unhashed uv pip freeze output; ours verifies hashed uv pip compile + pybuild-deps output). Manual rebase or Dependabot can refresh Action versions periodically.

Bootstrap window: until dymurray/mta-sync#1 merges and Dylan re-runs clone.sh (which registers the ours merge driver via git config merge.ours.driver true), the merge=ours attribute is a no-op on his local clone. The first sync after this PR lands would conflict on requirements.txt if upstream changed it in the meantime. Dylan resolves once with git checkout --ours kai_mcp_solution_server/requirements.txt .github/workflows/verify-requirements-txt.yml && ./scripts/post-sync.sh, or runs git config merge.ours.driver true in the kai clone first. After that, automated forever.

meson constraint caveat

requirements-build-constraints.txt pins meson==1.9.2 because >=1.10 publishes wheels only on PyPI and pybuild-deps errors on wheel-only sources. Pulled in transitively as a build dep of meson-python → numpy. When/if a newer meson regains an sdist, bump the pin and regen.

Verification

• uv pip install --dry-run --require-hashes -r requirements.txt resolves cleanly (3766 lines).
• requirements-build.txt is 65 pinned packages, every line carries --hash=sha256:.... (Note: this file legitimately contains duplicate pins for some packages — e.g. setuptools==81.0.0 AND setuptools==82.0.1 — because different runtime deps need different build-time setuptools versions. The file is consumed by Hermeto's prefetch, not by pip install -r.)
• The rewritten verify-requirements-txt.yml will run on this PR and confirms the regen is reproducible.
• Hermeto end-to-end acceptance: hand off to @ashwinsudhakaran to run against the art-tools#3047 build with hermeto --mode permissive fetch-deps pip against this branch.

cc @dymurray @ashwinsudhakaran

Refs: KONFLUX-14150, openshift-eng/art-tools#3047, dymurray/mta-sync#1

[coderabbitai]

Warning

Review limit reached

@fabianvf, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 41 minutes and 20 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more credits in the billing tab to continue.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: e5c0802f-e85a-44bf-a670-fb26ff3d48f4

📥 Commits

Reviewing files that changed from the base of the PR and between b3e8e39 and bcdc019.

📒 Files selected for processing (7)

• .gitattributes
• .github/workflows/verify-requirements-txt.yml
• kai_mcp_solution_server/requirements-build-constraints.txt
• kai_mcp_solution_server/requirements-build.txt
• kai_mcp_solution_server/requirements.txt
• konflux.solution-server.Dockerfile
• scripts/post-sync.sh

📝 Walkthrough

Walkthrough

This PR introduces hash-locked Python build dependencies using Hermeto's pybuild-deps tooling. The changes add a Makefile target to compile pinned build requirements, integrate verification into CI, configure Git merge handling for generated files, and automate regeneration on merge syncs and in Docker builds.

Changes

Hermeto Build Dependency Locking

Layer / File(s)	Summary
Build dependency locking infrastructure kai_mcp_solution_server/requirements-build-constraints.txt, kai_mcp_solution_server/Makefile, kai_mcp_solution_server/requirements-build.txt	Introduces requirements-build-constraints.txt pinning meson==1.9.2, the Makefile target regen-hermeto-requirements that merges constraints with requirements.txt and runs pybuild-deps, and the autogenerated requirements-build.txt with fully pinned build dependencies and SHA256 hashes.
CI verification workflow .github/workflows/verify-requirements-txt.yml	Replaces uv-based regeneration with a call to make regen-hermeto-requirements, copies both requirements*.txt pairs to committed snapshots, normalizes line endings, and diffs to detect staleness with updated error messages.
Git merge conflict prevention .gitattributes	Configures merge=ours strategy for kai_mcp_solution_server/requirements.txt and the workflow file to prevent merge conflicts on auto-generated content.
Deployment and regeneration automation konflux.solution-server.Dockerfile, scripts/post-sync.sh	Copies requirements-build.txt into the final Docker image alongside existing manifests, and adds a post-sync hook that runs make regen-hermeto-requirements to regenerate locked dependencies after dependency sync merges.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 Hermeto hops in with locked deps so tight,
Constraints and Makefiles arranged just right,
Build requirements pinned with hashes galore,
CI verifies, Docker deploys, sync hooks restore! ✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: adding hash-locked requirements for Hermeto permissive mode support in kai_mcp_solution_server.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

Warning

Review ran into problems

🔥 Problems

Stopped waiting for pipeline failures after 30000ms. One of your pipelines takes longer than our 30000ms fetch window to run, so review may not consider pipeline-failure results for inline comments if any failures occurred after the fetch window. Increase the timeout if you want to wait longer or run a @coderabbit review after the pipeline has finished.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 3

🧹 Nitpick comments (1)

.gitattributes (1)

1-2: ⚡ Quick win

Include requirements-build.txt in the same merge strategy as requirements.txt.

Given this PR’s lockfile contract, add kai_mcp_solution_server/requirements-build.txt merge=ours so both generated lock artifacts follow identical merge behavior.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.gitattributes around lines 1 - 2, Add the build lockfile to the
.gitattributes merge rule so it uses the same "ours" strategy as the existing
lockfile: update .gitattributes to include the entry
"kai_mcp_solution_server/requirements-build.txt merge=ours" (placed alongside
the existing "kai_mcp_solution_server/requirements.txt merge=ours") so both
generated lock artifacts follow identical merge behavior.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.gitattributes:
- Line 2: Remove the "merge=ours" attribute for the workflow path entry (the
".github/workflows/verify-requirements-txt.yml merge=ours" line) in
.gitattributes so CI workflow files are not forced to local content during
merges; instead either delete the attribute for that path or replace it with a
safer strategy (e.g., remove the line entirely or use a documented less
destructive merge strategy) to ensure upstream workflow/security updates aren’t
silently discarded.

In `@kai_mcp_solution_server/Makefile`:
- Around line 203-204: The Makefile invocation using "uvx --from pybuild-deps
pybuild-deps compile" must pin the pybuild-deps package to a fixed version so
regenerated requirements-build.txt is stable; update the Makefile (the rule
invoking uvx/pybuild-deps) to reference a specific version (e.g.,
pybuild-deps==<LOCKED_VERSION>) or add a PYBUILD_DEPS_VERSION variable and use
that in the uvx command, then regenerate and commit requirements-build.txt to
ensure future runs use the pinned pybuild-deps release.

In `@kai_mcp_solution_server/requirements-build.txt`:
- Around line 15-16: The requirements-build.txt contains conflicting duplicate
pins (e.g., package names cffi, hatchling, setuptools-scm, setuptools appear
with multiple versions), breaking hash-locked installs; regenerate or rebuild
the build lock so each package name is pinned only once (or split into separate
lock files per environment), remove or consolidate duplicate entries (keep the
intended version for cffi, hatchling, setuptools-scm, setuptools) and ensure
hashes match the chosen version; after regen, verify pip install
--require-hashes succeeds against the updated requirements-build.txt.

---

Nitpick comments:
In @.gitattributes:
- Around line 1-2: Add the build lockfile to the .gitattributes merge rule so it
uses the same "ours" strategy as the existing lockfile: update .gitattributes to
include the entry "kai_mcp_solution_server/requirements-build.txt merge=ours"
(placed alongside the existing "kai_mcp_solution_server/requirements.txt
merge=ours") so both generated lock artifacts follow identical merge behavior.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 877d42a6-1137-4073-b19e-ae7128549968

📥 Commits

Reviewing files that changed from the base of the PR and between 98430e0 and b3e8e39.

📒 Files selected for processing (8)

• .gitattributes
• .github/workflows/verify-requirements-txt.yml
• kai_mcp_solution_server/Makefile
• kai_mcp_solution_server/requirements-build-constraints.txt
• kai_mcp_solution_server/requirements-build.txt
• kai_mcp_solution_server/requirements.txt
• konflux.solution-server.Dockerfile
• scripts/post-sync.sh