konflux-ci/konflux-ci

What happened PR #9509 replaced plaintext credential storage (credential.helper store writing GH_TOKEN to ~/.git-credentials) with in-memory credential helpers across all 5 CI scripts under .github/, addressing security advisory GHSA-vp54-x7hx-6q7v. The old pattern persisted in the codebase from the scripts' inception until this fix. AGENTS.md has zero mentions of credential handling, secrets, or token management in CI scripts. What could go better AGENTS.md documents code style conventions (shell: set -euo pipefail, quote variables, POSIX constructs) and testing gaps (e.g., integrations/ not covered by e2e). It has no guidance on credential handling in CI scripts. If a contributor (human or agent) adds a new CI script that needs git authentication, there is no documented convention preventing reintroduction of the insecure file-based pattern. This is especially relevant for agent-authored code — agents read AGENTS.md but not security advisories. Confidence is high: the vulnerability

What happened On PR #9508, avi-biton modified 5 CI scripts/workflows under .github/ to replace plaintext credential storage with in-memory credential helpers. The fullsend review agent flagged .github/ as a protected path requiring human approval but did not flag the testability gap. Human reviewer yftacherzog commented that none of the changes are tested by the PR's CI pipeline and requested a temporary smoke test workflow to verify the credential helper works before merge. The author added the smoke test, which is the same pattern already documented for integrations/ in AGENTS.md line 69: "not covered by e2e; recommend a local-cluster check for script/version changes." What could go better AGENTS.md already documents that integrations/ changes aren't covered by e2e tests. The same gap exists for .github/scripts/ and .github/workflows/ — these scripts run on events like push, workflow_dispatch, or schedule, not pull_request, so changes to them land untested. Both human and agent rev

What happened In PR #9346, @avi-biton replicated the trusted-CA pattern from build-service to integration-service. The PR description explicitly stated it follows the same pattern as build-service. The human reviewer (@yftacherzog) compared test suites across the build-service and integration-service controllers and identified 3 test coverage gaps: (1) the new trustedCA BeforeEach did not use DeferCleanupParentAndChildren for its cluster-scoped ClusterRole/ClusterRoleBinding — a pattern used in 16 other test files across virtually every controller, (2) the trustedCAExists() helper already defined in the same Describe block was not reused for alignment with the build-service assertions, and (3) two subtests present in konfluxbuildservice_customization_test.go were not ported (preserves other volumes when trustedCA is set and TestReconcileEnsureTrustedCAConfigMapError). The fullsend review agent ran 3 times (Run 1, Run 2, Run 3) and missed all 3 issues. Its findings were limited to cos

Summary NewTrustedCAConfigMapMapper reads the component CR before it checks whether the ConfigMap is in the operand namespace. Follow-up to #9346. This does not enqueue extra reconciles; it does a cache read of the component CR on every ConfigMap event in the cluster. Background #9346 extracts trusted-CA handling into operator/internal/common/trusted_ca.go and uses NewTrustedCAConfigMapMapper from both the build-service and integration-service controllers. Both controllers watch ConfigMaps cluster-wide (one shared informer, two handlers). The previous build-service mapper returned immediately when the ConfigMap namespace did not match. The shared helper always calls lookup first: func NewTrustedCAConfigMapMapper(target TrustedCATarget, lookup TrustedCASpecLookup) func(ctx context.Context, obj client.Object) []reconcile.Request { return func(ctx context.Context, obj client.Object) []reconcile.Request { spec, err := lookup(ctx, target.CRName) return mapTrustedCAConfigMap(obj, target

operator/upstream-kustomizations/cli/create-tenant.sh creates both a konflux-integration-runner ServiceAccount and a RoleBinding of the same name after it creates the tenant namespace. This repository already deploys integration-service (96c1de4fd8c260d31049fe2bb12aa6b0d807797c). When that controller reconciles an IntegrationTestScenario, EnsureIntegrationPipelineServiceAccountCreated creates both objects in the scenario namespace if they are missing: ServiceAccount konflux-integration-runner RoleBinding konflux-integration-runner, which binds that ServiceAccount to ClusterRole konflux-integration-runner Those are the same objects the script applies. The controller does this only while reconciling a scenario, which is before integration pipelines for that scenario run. The script does not need to create them. The default-tenant manifest is separate. The default-tenant controller applies this ServiceAccount and RoleBinding only in the default-tenant namespace, and this issue does not