[Konflux] isolate frontend and backend config schemas

[rrosatti]

User description

Hey, I just made a Pull Request!

In a previous PR (#2212) we tried to fix the schema visibility issue, but the fix wasn't enough.
This PR completes the Konflux config split by moving the frontend schema into the konflux plugin and keeping backend/secret fields in konflux-backend. This "should" 🙏 prevent backend schema exports from inheriting frontend visibility and fixes the frontend/secret conflict during dynamic schema merge.

Error observed is same/similar with the one pointed out in the previous PR:
Config schema visibility is both 'frontend' and 'secret' for konflux.clusters.*.serviceAccountToken.

Repro:

• installed OCI test packages (pr_1860__0.1.1 / pr_1860__0.1.2)
• backend fails on startup with core.dynamicplugins.frontendSchemas

✔️ Checklist

• A changeset describing the change and affected packages. (more info)
• Added or Updated documentation
• Tests for new functionality and regression tests for bug fixes
• Screenshots attached (for UI changes)

---

PR Type

Bug fix, Enhancement

---

Description

• Separate frontend and backend config schemas to resolve visibility conflicts

• Move backend-only fields to konflux-backend plugin with proper visibility markers

• Remove config schema from konflux-common to prevent inheritance issues

• Add frontend config schema to main konflux plugin for UI-accessible fields

---

Diagram Walkthrough

flowchart LR
  A["konflux-common<br/>package.json"] -- "remove config.d.ts<br/>and configSchema" --> B["Simplified common<br/>package"]
  C["konflux-backend<br/>config.d.ts"] -- "add backend fields<br/>with visibility markers" --> D["Backend-only<br/>configuration"]
  E["konflux<br/>package.json"] -- "add config.d.ts<br/>and configSchema" --> F["Frontend<br/>configuration"]
  B --> G["Prevent schema<br/>inheritance conflicts"]
  D --> G
  F --> G

Loading

File Walkthrough

	Relevant files
Configuration changes	config.d.ts Add backend config schema with visibility markers                workspaces/konflux/plugins/konflux-backend/config.d.ts Add @visibility backend markers to all backend configuration fields Define backend-specific fields: authProvider, uiUrl, openshiftConsoleUrl, kubearchiveApiUrl, apiUrl Keep serviceAccountToken marked as @visibility secret Establish complete backend schema definition in backend plugin +14/-0    package.json Remove config schema from common package                                  workspaces/konflux/plugins/konflux-common/package.json Remove config.d.ts from files array Remove configSchema field from package.json Eliminate schema inheritance from common package +2/-4      package.json Add config schema to frontend plugin                                          workspaces/konflux/plugins/konflux/package.json Add config.d.ts to files array Add configSchema field pointing to config.d.ts Enable frontend plugin to export its own configuration schema +4/-2
Documentation	shaky-queens-sort.md Add changeset for schema visibility fix                                    workspaces/konflux/.changeset/shaky-queens-sort.md Create changeset documenting schema separation across three packages Mark changes as patch version updates Document fix for visibility conflict resolution +7/-0

---

[rhdh-gh-app]

Changed Packages

Package Name	Package Path	Changeset Bump	Current Version
@red-hat-developer-hub/backstage-plugin-konflux-backend	workspaces/konflux/plugins/konflux-backend	patch	v0.1.2
@red-hat-developer-hub/backstage-plugin-konflux-common	workspaces/konflux/plugins/konflux-common	patch	v0.1.2
@red-hat-developer-hub/backstage-plugin-konflux	workspaces/konflux/plugins/konflux	patch	v0.1.2

[rhdh-qodo-merge]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
🟢	No codebase code duplication found No new components were introduced in the PR code
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

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rhdh-qodo-merge]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
High-level	Populate the new frontend configuration schema The new frontend configuration schema file, plugins/konflux/config.d.ts, is empty. It should be populated with the necessary frontend-specific configuration properties and @visibility frontend markers. Examples: workspaces/konflux/plugins/konflux/package.json [80-82] "config.d.ts" ], "configSchema": "config.d.ts" Solution Walkthrough: Before: // file: workspaces/konflux/plugins/konflux/config.d.ts // This file is empty. After: // file: workspaces/konflux/plugins/konflux/config.d.ts export interface Config { /** @visibility frontend */ konflux?: { /** @visibility frontend */ clusters?: { [key: string]: { /** @visibility frontend */ uiUrl?: string; /** @visibility frontend */ openshiftConsoleUrl?: string; }; }; }; } Suggestion importance[1-10]: 9 __ Why: The suggestion correctly identifies that the new frontend configuration schema is empty, which is a critical omission that would prevent the frontend plugin from accessing its configuration.	High
General	Add missing visibility annotation to property Add the @visibility backend annotation to the clusters property in the konflux configuration to ensure explicit visibility and avoid ambiguity. workspaces/konflux/plugins/konflux-backend/config.d.ts [23] /** @visibility backend */ authProvider?: 'serviceAccount' | 'oidc' | 'impersonationHeaders'; /** @visibility backend */ clusters?: { + /** @visibility backend */ [key: string]: { /** @visibility backend */ uiUrl?: string; [To ensure code accuracy, apply this suggestion manually] Suggestion importance[1-10]: 5 __ Why: The suggestion correctly identifies that the clusters property is missing a @visibility backend annotation for consistency, which is a valid point for improving code clarity and maintainability.	Low
More