fix: fix e2e release-branch

[bouskaJ]

PR Type

Bug fix

---

Description

• Fix e2e test pipeline to use hardcoded main branch

• Resolve release branch parameter mismatch in resolver configuration

---

Diagram Walkthrough

flowchart LR
  A["e2e.yaml config"] -- "update revision value" --> B["Use main branch"]
  B -- "instead of" --> C["Dynamic branch parameter"]

Loading

File Walkthrough

	Relevant files
Bug fix	e2e.yaml Update e2e resolver revision to main branch                            konflux-configs/base/project/overlay/rhtas-operator/patch/e2e.yaml Changed resolver revision parameter from dynamic {{.branch}} to hardcoded main Fixes mismatch between releaseBranch param and resolver git revision Ensures e2e test pipeline uses stable main branch for pipeline resolution +1/-1

---

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
⚪	Unpinned git revision Description: The PipelineRun is resolved from a remote git repository (https://github.com/securesign/pipelines.git) using a floating branch reference (revision: main), which can enable a supply-chain risk where upstream changes to main alter executed CI/CD logic without review (prefer pinning to a commit SHA or a signed/tagged immutable reference). e2e.yaml [18-26] Referred Code resolverRef: params: - name: url value: https://github.com/securesign/pipelines.git - name: revision value: main - name: pathInRepo value: pipelines/integration-test/rhtas-operator-e2e.yaml resolver: git
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Passed Learn more about managing compliance generic rules or creating your own custom rules

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Use a git tag for stability To improve test stability, replace the hardcoded main branch revision with a specific, immutable git tag (e.g., v1.2.3). This ensures tests on release branches use a compatible and reproducible pipeline version. konflux-configs/base/project/overlay/rhtas-operator/patch/e2e.yaml [22-23] - name: revision - value: main + value: <latest-stable-tag> # e.g., v1.2.3 Apply / Chat Suggestion importance[1-10]: 7 __ Why: The suggestion correctly points out that using the main branch for revision can lead to instability and proposes a more robust solution by using a stable git tag, which aligns with best practices for release management.	Medium
More

[github-actions]

Configuration Diff

1 document(s) impacted:

+ 0 added
- 0 removed
! 1 modified

Diff

@@ spec.resources.appstudio.redhat.com/v1beta2/IntegrationTestScenario/rhtas-operator-e2e-test{{.nameSuffix}}.spec.resolverRef.params.revision.value @@
# projctl.konflux.dev/v1beta1/ProjectDevelopmentStreamTemplate/rhtas-tenant/operator-template
! ± value change
- {{.branch}}
+ main

---

_{📦 Artifacts: base-output.yaml, head-output.yaml, dyff-output.txt}