[FEATURE] Add Feature Gates Support to ShipwrightBuild CRD

[ayushsatyam146]

Is there an existing feature request for this?

• I have searched the existing feature requests

Is your feature request related to a problem or use-case? Please describe.

Currently, the Shipwright operator does not provide a way to enable/disable specific features at the operator level. While some features can be controlled at the build controller level, there's no mechanism to manage these through the ShipwrightBuild custom resource for the entire cluster.

Describe the solution that you would like.

Add a featureGates field to the ShipwrightBuild CRD spec to allow operators to enable/disable specific features when deploying Shipwright Build controller.

apiVersion: shipwright.io/v1alpha1
kind: ShipwrightBuild
metadata:
  name: cluster
spec:
  featureGates:
    vulnerabilityScan: false  # disabled by default
    runtimeImage: true
    # other features...

Implementation Details

1. Update the ShipwrightBuild CRD to include the new featureGates field
2. Modify the operator controller to pass these configurations to the Shipwright Build controller deployment
3. Update the deployment manifest to include the feature gates as environment variables or configuration

The operator should:

• Validate feature gate names against known features
• Set appropriate default values based on feature stability (Alpha/Beta/GA)
• Pass the configuration to the Build controller deployment

Benefits

• Consistent feature management across cluster deployments
• Ability to enable/disable experimental features at deployment time
• Better control over feature rollout in production environments

Risks and Mitigations

• Breaking changes to existing deployments: Mitigate by making the field optional with sensible defaults
• Feature gate naming conflicts: Ensure alignment with upstream Shipwright Build feature gates
• Configuration complexity: Provide clear documentation and examples

Questions

• What features in the Build controller should be enabled/disabled via the operator?
• How should we handle feature gate changes after initial deployment?
• Should we add validation webhooks to prevent invalid feature gate configurations?

Describe alternatives you have considered.

No response

Anything else?

No response

[adambkaplan]

A hearty 👍 to this feature! I'll tackle some of the risks + questions in my comments below:

Risks:

Breaking changes to existing deployments: Mitigate by making the field optional with sensible defaults

Agree - any feature gate we add should be an optional value. Kubernetes API conventions do not recommend using booleans. I recommend using Enabled + Disabled as the initial allowed values for a given feature gate. This lets the operator decide what should be enabled or disabled by default if no value is provided.

Feature gate naming conflicts: Ensure alignment with upstream Shipwright Build feature gates

Agree here

Questions:

What features in the Build controller should be enabled/disabled via the operator?

I recommend creating sub-issues on this for each individual feature that can be configured in the build controller (ex: via an environment variable). We can then discuss and decide which ones to add to the operator.

How should we handle feature gate changes after initial deployment?

Good question. I think there is a bit more nuance here:

• How do we handle rolling out feature gate changes to the build controller? Most likely via environment variables.
• How do we handle feature gates that "graduate" to GA (i.e. always on, can't be turned off)?

Should we add validation webhooks to prevent invalid feature gate configurations?

Only if we absolutely need it. I think having the operator controller overwrite invalid config values is fine (and normal).