diff --git a/ships/0038-shipwright-build-strategy-controller.md b/ships/0038-shipwright-build-strategy-controller.md new file mode 100644 index 0000000..107bb11 --- /dev/null +++ b/ships/0038-shipwright-build-strategy-controller.md @@ -0,0 +1,179 @@ + + +--- +title: shipwright-build-strategy-controller +authors: + - "@jkhelil" +reviewers: + - "@adambkaplan" + - "@qu1queee" +approvers: + - "@adambkaplan" + - "@qu1queee" +creation-date: 2023-10-02 +last-updated: 2023-10-02 +status: implementable +--- + +## Release Signoff Checklist + +- [x] Enhancement is `implementable` +- [x] Design details are appropriately documented from clear requirements +- [x] Test plan is defined +- [ ] Graduation criteria for dev preview, tech preview, GA +- [ ] User-facing documentation is created in [docs](/docs/) + +## Open Questions [optional] + + +## Summary + +This ship proposes support of installing a catalog of Build Strategies +via the shipwright operator in order to improve the user experience around Shipwright Build + +## Motivation + +Actually with the Shipwright operator, the user installs the Shipwright Build Controller. +Installation and upgrade of Build Strategies and Cluster Strategies is currently a manual process +In order to improve user experience around Shipwright, the Shipwright Operator should also install the build strategies. + +### Goals + +- Create a Build Strategy catalog repository in the upstream shipwright-io organization +- Copy/publish the Build strategies from the upstream build repository to the new create catalog repository +- Allow a user to install the default Build Strategy Catalog or if applicable the user provided catalog, via the Shipwright Operator + +### Non-Goals + +- Add a new operator to install the Build Strategy catalog +- Curate or rework the Build Strategies in the upstream build repository when copied to the new catalog repository + +## Proposal + +We propose to add new field `strategyCatalog` to the `spec` of ShipwrightBuild CRD. +The `strategyCatalog` field represents the type of source strategy catalog we use as source to install build strategies. +In the current SHIP we propose one type of source catalog : source catalog of type git representing a repository url where the strategies are commited. + +```yaml +apiVersion: operator.shipwright.io/v1alpha1 +kind: ShipwrightBuild +metadata: + name: buildStrategy +spec: + targetNamespace: shipwright-build + strategyCatalog: + type: git + url: https://github.com/shipwright-io/buildstrategy-catalog + revision: v0.1.0 +``` +We propose to add a new controller to the Shipwright Operator that reconciles the ShipwrightBuild, fetches the manifests from the catalog, +installs them, and updates the `ShipwrightBuild` status + + +### User Stories [optional] + +#### Story 1 + +As a Kubernetes cluster administrator +I want to be able to install the default catalog of Shipwright Builds Strategies via the Shipwright Operator +So that I can provide Shipwright Build Strategies to my developers + + +#### Story 2 + +As a Kubernetes cluster administrator +I want to be able to provide a git repository url and install my own catalog of Shipwright Builds Strategies via the Shipwright Operator +So that I can provide a custom subset of Shipwright Build Strategies to my developers + +### Implementation Notes + +#### API + +The proposal adds the new optional field `strategyCatalog` to the `ShipwrightBuild` resource specification. it allow multiple types. +The current SHIP will add support to the `git` type. Other source catalog types can be added in the future. + +The following snippet shows how the `ShipwrightBuildSpec` will be represented. + +```go +type ShipwrightBuildSpec struct { + // TargetNamespace is the target namespace where Shipwright's build controller will be deployed. + TargetNamespace string `json:"targetNamespace,omitempty"` + // strategyCatalog refers to a source catalog containing strategies manifests to be installed. + StrategyCatalog StrategyCatalog `json:"strategyCatalog"` +} + +type StrategyCatalog struct { + // Type is the StrategyCatalogType qualifier, the type of the data-source. + // + // +optional + Type StrategyCatalogType `json:"type,omitempty"` + + // GitSource + // + // +optional + GitSource *Git `json:"git,omitempty"` +} + +type Git struct { + // URL describes the URL of the Git repository. + // + // +optional + URL *string `json:"url,omitempty"` + + // Revision describes the Git revision (e.g., branch, tag, commit SHA, + // etc.) to fetch. + // + // If not defined, it will fallback to the repository's default branch. + // + // +optional + Revision *string `json:"revision,omitempty"` + + // CloneSecret references a Secret that contains credentials to access + // the repository. + // + // +optional + CloneSecret *string `json:"cloneSecret,omitempty"` +} +``` + +#### Controller + +Actually the Shipwright Operator uses controller-runtime package to bootstrap a manager and setup the Shipwright Build controller within that manager. +In the target implementation we will continue using controller-runtime +We will split the controllers each acheiving a specific function in its own package: +- shipwrightbuild controller to reconcile ShipwrightBuild CRD and installs Shipwright Build manifests in the `targetNamespace` +- shipwrightbuilstrategy controller to reconcile ShipwrightBuild CRD and installs Shipwright Build Strategy catalog. +The main package will bootstrap a controller manager and adds all the controllers to the manager. + +### Test Plan + +The implementation has to be tested on a `unit`, `integration` and `e2e` level to ensure correctness. + +### Release Criteria + +tbd + +### Risks and Mitigations + +**Risk**: The default strategy catalog or any url provided catalog can be unreachable if the kubernetes cluster needs a proxy to access to the catalog url +**Mitigation**: A future implemenation will be proposed to handle proxy settings + +**Risk**: The default strategy catalog or any url provided catalog can be unreachable if the kubernetes cluster is a disconnected cluster and does not have any access to internet +**Mitigation**: +- A new type of source catalog will be proposed using oci artifcats. + +## Drawbacks + + +## Alternatives + + +## Infrastructure Needed [optional] + + +## Implementation History +