Add shipwright-build-strategy-controller SHIP

ships/0038-shipwright-build-strategy-controller.md

@@ -0,0 +1,164 @@
+<!--
+Copyright The Shipwright Contributors
+
+SPDX-License-Identifier: Apache-2.0
+-->
+
+---
+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 http representing an url of a tarball containing the strategies.
+
+```yaml
+apiVersion: operator.shipwright.io/v1alpha1
+kind: ShipwrightBuild
+metadata:
+  name: buildStrategy
+spec:
+  targetNamespace: shipwright-build
+  strategyCatalog:
+    type: http
+    url: https://github.com/shipwright-io/buildstrategy-catalog/archive/refs/tags/v0.11.0.tar.gz
+```
+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 tarball 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 `http` 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"`
+
+	// HttpSource
+	//
+	// +optional
+	HttpSource *Http `json:"http,omitempty"`
+}
+
+type Http struct {
+	// URL describes the URL of the tarball repository.
+	//
+	// +optional
+	URL *string `json:"url,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
+