Repository navigation
Konflux support - #862
Open
TomasKorbar wants to merge 5 commits into
Open
Konflux support#862TomasKorbar wants to merge 5 commits into
TomasKorbar wants to merge 5 commits into
Conversation
Introduce BUILD_BACKEND (copr default | konflux) to swap the build-validation step from Copr to Konflux without touching the agent workflows. The gateway registers backend-specific tools under the same names (build_package, download_artifacts), so the agents stay backend-agnostic. Konflux builds from a pushed git ref rather than a local SRPM, so the backport workflow commits + pushes the fork branch before building and opens the MR only after a green build (konflux_build_and_publish / konflux_inherit_build). The fork is created even under DRY_RUN (only MR/Jira writes stay suppressed); Copr is unchanged. The Konflux tool submits a PipelineRun against one fixed, generic Component (ymir-scratch-build in ymir-tenant) whose build-service-provisioned ServiceAccount carries appstudio-pipelines-scc and whose image repo receives the scratch build; git-url + revision are overridden per run, so a single Component backs every package with no cross-tenant RBAC. Target defaults are baked in and overridable via KONFLUX_NAMESPACE / KONFLUX_SERVICE_ACCOUNT / KONFLUX_IMAGE_REPO. Builds are x86_64-only. It omits the appstudio application/component labels so no Snapshot/Release is created (no brew/koji import) -- Ymir only needs the build to pass as validation. Failure logs come from authenticated Kubearchive pod-log URLs. Verified end-to-end: the backport-agent konflux e2e passed with a real PipelineRun reaching Succeeded under the fixed target. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
When the backport or rebase workflow reruns for a Jira issue, it force-pushes the deterministic update branch (automated-package-update- <issue>). Any merge request still open on that branch picks up the push and re-runs its GitLab CI pipeline — a wasted scratch build on an MR the rerun is about to supersede. Close the lingering MR first, so only the rerun's eventual fresh MR runs CI once. Both agents gain a close_stale_merge_requests workflow step that runs after the Jira status change / sibling resolution and before the fork, via a new tasks.close_stale_update_merge_requests helper and a new privileged close_merge_request GitLab tool. The close is scoped to the bot's own update branch (matched on source_branch) targeting the dist-git branch, so human MRs referencing the issue are never touched. It is a GitLab write, so it is suppressed under DRY_RUN, and the backport inherited-publication resume path skips it (it deliberately reuses its own MR). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The fix agent used to build the package itself, which was the only build validation on the Copr path; Konflux re-validated separately in konflux_build_and_publish. This asymmetry meant the two backends took different paths after a build failure. Rework the loop so a single build step is the only builder for both backends. The fix agent now produces a corrected backport (regenerated patches plus a fresh SRPM) but never builds; routing returns to the one build step via the new _post_backport_build_step() helper, and on build failure routes back to fix_build_error carrying state.build_error. Gate the fix agent with include_build_tools=False (build_srpm/run_package_prep stay available so it can still regenerate and verify the SRPM) and centralize build-log archiving in fix_build_error. Rewrite prompt_fix_build_error.j2 to be backend-agnostic and drop all in-agent build instructions. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The backport workflow now traverses one step graph for both build backends; the backend abstraction lives only in gateway tool selection and run_build log detection, never in the workflow routing. - Both backends commit and push before building: the single build step commit_push_and_build builds the pushed ref (Konflux) or the generated SRPM (Copr), opening the MR only after a green build. The Y-stream inherit path likewise shares one sequence ending in validate_inherited_build. Copr dry-run now creates a fork and pushes like Konflux, so gitlab.py always forks. - Squash build/fix retries: commit_push_and_build soft-resets to the pristine base before committing, so each backport lands as exactly one commit with no agent attempts in history. - Make the build-failure diagnosis prompt backend-neutral: the gateway-log (Konflux) branch no longer references Copr's builder-live.log/root.log, whose equivalents are named per pod there. - Remove the redundant _post_backport_build_step indirection that always returned "update_release". Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The Copr/Konflux workflow unification routes both backends through build_agent.run_build, which dumps the full shared BuildInputSchema to the build_package tool. The Copr tool therefore now receives the Konflux-only fields (git_url, revision, package_name, target_branch). BuildPackageToolInput lacked extra="allow", so beeai's MCP client - which rebuilds the input model from the advertised JSON schema with extra="forbid" unless additionalProperties is truthy - rejected those fields client-side as "Tool input validation error" before the build reached the gateway. Add ConfigDict(extra="allow") (mirroring the Konflux tool) so the schema advertises additionalProperties: true. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
cgwalters
reviewed
Oct 8, 2026
cgwalters
left a comment
cgwalters
left a comment
Contributor
There was a problem hiding this comment.
This is cool, though...what I'd been thinking is basically we have a flow like:
- Ymir verifies the thing passes at least
rhpkg prepin a container image. - Ymir opens draft MR and iterates from there, automatically fixing and monitoring CI as it goes
We'd add support for labels that can be added to a MR for RoK that support e.g. "only build on cloud architectures" etc.
This would give a lot more visibility into what the agents are doing for developers. And there's an opportunity to have direct human interaction - let's say the agent is flailing and hits iteration loops/token spend limits, it can ping the maintainer on the draft MR.
Or a maintainer can comment while an MR is running.
In my personal agent harness, the framework (e.g. opencode) is handled via Agent Client Protocol, so there's space to have dynamic injection of context like ("new comments on the MR").
| SUCCESSFUL_STATES = frozenset({"Succeeded", "Completed"}) | ||
|
|
||
| # Single-arch scratch validation (mirrors COPR building one arch for speed). | ||
| DEFAULT_BUILD_ARCHITECTURES = ["x86_64"] |
Contributor
There was a problem hiding this comment.
I think this is the type of stuff that's probably better in a separate config file
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.