feat(extensions-schema): allow production support level for plugin metadata

[polasudo]

Jira: https://issues.redhat.com/browse/RHIDP-12372

User description

Summary

• add production to the allowed enum values for spec.support.level in workspaces/extensions/json-schema/plugins.json
• keep existing allowed values unchanged for backward compatibility

Why

Overlays metadata is being normalized to use production consistently. This schema update ensures plugin metadata validates correctly when that value is used.

Test plan

• schema includes production in support.level enum
• existing values (generally-available, tech-preview, dev-preview, community, none) remain supported

Made with Cursor

---

PR Type

Enhancement

---

Description

• Add production to allowed enum values for spec.support.level

• Enables plugin metadata to use production support level consistently

• Maintains backward compatibility with existing support level values

---

Diagram Walkthrough

flowchart LR
  schema["plugins.json schema"] -- "add production enum value" --> support["support.level enum"]
  support -- "includes" --> values["production, generally-available, tech-preview, dev-preview, community, none"]

Loading

File Walkthrough

	Relevant files
Enhancement	plugins.json Add production to support level enum                                          workspaces/extensions/json-schema/plugins.json Added production to the spec.support.level enum values Positioned as first enum value in the list All existing support level values remain unchanged and supported +1/-0

---

[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
Update

Compliance status legend

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

[rhdh-qodo-merge]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
General	✅ Clarify potentially confusing enum values Suggestion Impact: Instead of adding a descriptive text to clarify the enum values, the commit removed the "generally-available" enum option from the schema, reducing the ambiguity the suggestion called out but not implementing the proposed description field. code diff: @@ -129,7 +129,6 @@ "type": "string", "enum": [ "production", - "generally-available", "tech-preview", "dev-preview", "community", Add a description field to the level property in the JSON schema to clarify the meaning of each support level, especially the distinction between production and generally-available. workspaces/extensions/json-schema/plugins.json [128-135] "level": { "type": "string", + "description": "Defines the support level of the plugin. 'production' is for fully supported, production-ready plugins. 'generally-available' is for stable releases that are not yet at full production support. 'tech-preview' and 'dev-preview' are for pre-release versions. 'community' is for community-supported plugins.", "enum": [ "production", "generally-available", "tech-preview", "dev-preview", "community", ... [To ensure code accuracy, apply this suggestion manually] Suggestion importance[1-10]: 6 __ Why: The suggestion correctly identifies that the terms production and generally-available can be ambiguous and proposes adding a description to the JSON schema, which is a good practice for clarity and usability.	Low
Update

[rhdh-gh-app]

Important

This PR includes changes that affect public-facing API. Please ensure you are adding/updating documentation for new features or behavior.

Missing Changesets

The following package(s) are changed by this PR but do not have a changeset:

• @red-hat-developer-hub/backstage-plugin-extensions

See CONTRIBUTING.md for more information about how to add changesets.

Changed Packages

Package Name	Package Path	Changeset Bump	Current Version
@red-hat-developer-hub/backstage-plugin-extensions-common	workspaces/extensions/plugins/extensions-common	minor	v0.14.5
@red-hat-developer-hub/backstage-plugin-extensions	workspaces/extensions/plugins/extensions	none	v0.14.5

[dzemanov]

Tested this works correctly:

[dzemanov]

/approve
/lgtm

Thank you!

[christoph-jerolimov]

I like to understand this (to me) ad hoc change of an API before we continue.

[nickboldt]

I like to understand this (to me) ad hoc change of an API before we continue.

Well, to quote myself in RHIDP-12372:

we want to be consistent with the metadata, because obvious reasons.

If you would prefer to use generally-available everywhere instead of production, I'm fine with that. The point was to be CONSISTENT, not to force an API change.

cc: @kim-tsao

[openshift-ci]

New changes are detected. LGTM label has been removed.

[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

[polasudo]

After discussion, we're keeping generally-available as a support level term. Main already uses this consistently, so no changes are needed. Closing this PR for now. If in need it can be reopened later