Rename Shipwright components away from "operator"

.github/workflows/ci.yml

@@ -110,12 +110,12 @@ jobs:
           run: curl -fsL https://github.com/google/ko/releases/download/v0.8.0/ko_0.8.0_Linux_x86_64.tar.gz | sudo tar xzf - -C /usr/local/bin ko
         - name: Install Shipwright Build
           run: |
-            make install-operator-kind
-            kubectl -n build-operator rollout status deployment build-operator --timeout=1m || true
+            make install-controller-kind
+            kubectl -n shipwright-build rollout status deployment shipwright-build-controller --timeout=1m || true
         - name: Test
-          run: TEST_E2E_OPERATOR=managed_outside TEST_NAMESPACE=build-operator TEST_IMAGE_REPO=registry.registry.svc.cluster.local:32222/shipwright-io/build-e2e make test-e2e
-        - name: Build operator logs
+          run: TEST_E2E_OPERATOR=managed_outside TEST_NAMESPACE=shipwright-build TEST_IMAGE_REPO=registry.registry.svc.cluster.local:32222/shipwright-io/build-e2e make test-e2e
+        - name: Build controller logs
           if: ${{ failure() }}
           run: |
-            POD_NAME=$(kubectl -n build-operator get pod -o json | jq -r '.items[0].metadata.name')
-            kubectl -n build-operator logs "${POD_NAME}"
+            POD_NAME=$(kubectl -n shipwright-build get pod -o json | jq -r '.items[0].metadata.name')
+            kubectl -n shipwright-build logs "${POD_NAME}"

DEVELOPMENT.md

@@ -159,6 +159,6 @@ You can clean up everything with:
 To look at the operator logs, run:
 
 ```sh
-kubectl -n build-operator logs $(kubectl -n build-operator get pods -l name=build-operator -o name)
+kubectl -n shipwright-build logs $(kubectl -n shipwright-build get pods -l name=shipwright-build-controller -o name)
 ```
 

Makefile

@@ -2,8 +2,8 @@ SHELL := /bin/bash
 
 # output directory, where all artifacts will be created and managed
 OUTPUT_DIR ?= build/_output
-# relative path to operator binary
-OPERATOR = $(OUTPUT_DIR)/bin/build-operator
+# relative path to controller binary
+OPERATOR = $(OUTPUT_DIR)/bin/shipwright-build-controller
 
 # golang cache directory path
 GOCACHE ?= $(shell echo ${PWD})/$(OUTPUT_DIR)/gocache
@@ -27,7 +27,7 @@ OPERATOR_SDK_EXTRA_ARGS ?= --debug
 # test namespace name
 TEST_NAMESPACE ?= default
 
-# CI: tekton pipelines operator version
+# CI: tekton pipelines controller version
 TEKTON_VERSION ?= v0.20.1
 # CI: operator-sdk version
 SDK_VERSION ?= v0.18.2
@@ -83,19 +83,19 @@ vendor: go.mod go.sum
 build: $(OPERATOR)
 
 $(OPERATOR): vendor
-	go build -trimpath $(GO_FLAGS) -o $(OPERATOR) cmd/manager/main.go
+	go build -trimpath $(GO_FLAGS) -o $(OPERATOR) cmd/controller/main.go
 
 .PHONY: build-plain
 build-plain: 
-	go build -trimpath $(GO_FLAGS) -o $(OPERATOR) cmd/manager/main.go
+	go build -trimpath $(GO_FLAGS) -o $(OPERATOR) cmd/controller/main.go
 
 .PHONY: build-image
 build-image:
-	KO_DOCKER_REPO="$(IMAGE_HOST)/$(IMAGE)" GOFLAGS="$(GO_FLAGS)" ko publish --bare ./cmd/manager
+	KO_DOCKER_REPO="$(IMAGE_HOST)/$(IMAGE)" GOFLAGS="$(GO_FLAGS)" ko publish --bare ./cmd/controller
 
 .PHONY: build-image-with-pprof
 build-image-with-pprof:
-	KO_DOCKER_REPO="$(IMAGE_HOST)/$(IMAGE)" GOFLAGS="$(GO_FLAGS) -tags=pprof_enabled" ko publish --bare --tags=pprof ./cmd/manager
+	KO_DOCKER_REPO="$(IMAGE_HOST)/$(IMAGE)" GOFLAGS="$(GO_FLAGS) -tags=pprof_enabled" ko publish --bare --tags=pprof ./cmd/controller
 
 .PHONY: release
 release:
@@ -231,7 +231,7 @@ test-e2e-plain: ginkgo
 	TEST_E2E_VERIFY_TEKTONOBJECTS=${TEST_E2E_VERIFY_TEKTONOBJECTS} \
 	$(GINKGO) ${TEST_E2E_FLAGS} test/e2e
 
-.PHONY: install install-apis install-operator install-strategies
+.PHONY: install install-apis install-controller install-strategies
 
 install:
 	KO_DOCKER_REPO="$(IMAGE_HOST)/$(IMAGE)" GOFLAGS="$(GO_FLAGS)" ko apply --bare -R -f deploy/
@@ -244,21 +244,21 @@ install-apis:
 	# Wait for the CRD type to be established; this can take a second or two.
 	kubectl wait --timeout=10s --for condition=established crd/clusterbuildstrategies.build.dev
 
-install-operator: install-apis
+install-controller: install-apis
 	KO_DOCKER_REPO="$(IMAGE_HOST)/$(IMAGE)" GOFLAGS="$(GO_FLAGS)" ko apply --bare -f deploy/
 
-install-operator-kind: install-apis
+install-controller-kind: install-apis
 	KO_DOCKER_REPO=kind.local GOFLAGS="$(GO_FLAGS)" ko apply -f deploy/
 
 install-strategies: install-apis
 	kubectl apply -R -f samples/buildstrategy/
 
 local: vendor install-strategies
-	OPERATOR_NAME=build-operator \
+	OPERATOR_NAME=shipwright-build-controller \
 	operator-sdk run local --operator-flags="$(ZAP_FLAGS)"
 
 local-plain: vendor
-	OPERATOR_NAME=build-operator \
+	OPERATOR_NAME=shipwright-build-controller \
 	operator-sdk run local --operator-flags="$(ZAP_FLAGS)"
 
 clean:

build/Dockerfile

@@ -4,12 +4,12 @@
 
 FROM registry.access.redhat.com/ubi8/ubi-minimal:latest
 
-ENV OPERATOR=/usr/local/bin/build-operator \
+ENV OPERATOR=/usr/local/bin/shipwright-build-controller \
     USER_UID=1001 \
-    USER_NAME=build-operator
+    USER_NAME=shipwright-build-controller
 
 # install operator binary
-COPY build/_output/bin/build-operator ${OPERATOR}
+COPY build/_output/bin/shipwright-build-controller ${OPERATOR}
 
 COPY build/bin /usr/local/bin
 RUN  /usr/local/bin/user_setup

build/bin/entrypoint

@@ -10,7 +10,7 @@
 
 if ! whoami &>/dev/null; then
   if [ -w /etc/passwd ]; then
-    echo "${USER_NAME:-build-operator}:x:$(id -u):$(id -g):${USER_NAME:-build-operator} user:${HOME}:/sbin/nologin" >> /etc/passwd
+    echo "${USER_NAME:-shipwright-build-controller}:x:$(id -u):$(id -g):${USER_NAME:-shipwright-build-controller} user:${HOME}:/sbin/nologin" >> /etc/passwd
   fi
 fi
 

cmd/manager/main.go → cmd/controller/main.go

@@ -91,7 +91,7 @@ func main() {
 
 	mgr, err := controller.NewManager(ctx, buildCfg, cfg, manager.Options{
 		LeaderElection:          true,
-		LeaderElectionID:        "build-operator-lock",
+		LeaderElectionID:        "shipwright-build-controller-lock",
 		LeaderElectionNamespace: buildCfg.ManagerOptions.LeaderElectionNamespace,
 		LeaseDuration:           buildCfg.ManagerOptions.LeaseDuration,
 		RenewDeadline:           buildCfg.ManagerOptions.RenewDeadline,

deploy/namespace.yaml → deploy/100-namespace.yaml

@@ -1,4 +1,4 @@
 apiVersion: v1
 kind: Namespace
 metadata:
-  name: build-operator
+  name: shipwright-build

deploy/role.yaml → deploy/200-role.yaml

@@ -1,7 +1,7 @@
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
 metadata:
-  name: build-operator
+  name: shipwright-build-controller
 rules:
 - apiGroups:
   - ""
@@ -48,7 +48,7 @@ rules:
 - apiGroups:
   - apps
   resourceNames:
-  - build-operator
+  - shipwright-build
   resources:
   - deployments/finalizers
   verbs:

deploy/role_binding.yaml → deploy/300-rolebinding.yaml

@@ -1,12 +1,12 @@
 kind: ClusterRoleBinding
 apiVersion: rbac.authorization.k8s.io/v1
 metadata:
-  name: build-operator
+  name: shipwright-build-controller
 subjects:
 - kind: ServiceAccount
-  name: build-operator
-  namespace: build-operator
+  name: shipwright-build-controller
+  namespace: shipwright-build
 roleRef:
   kind: ClusterRole
-  name: build-operator
+  name: shipwright-build-controller
   apiGroup: rbac.authorization.k8s.io

deploy/400-serviceaccount.yaml

@@ -0,0 +1,5 @@
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  name: shipwright-build-controller
+  namespace: shipwright-build

deploy/operator.yaml → deploy/500-controller.yaml

@@ -1,37 +1,37 @@
 apiVersion: apps/v1
 kind: Deployment
 metadata:
-  name: build-operator
-  namespace: build-operator
+  name: shipwright-build-controller
+  namespace: shipwright-build
 spec:
   replicas: 1
   selector:
     matchLabels:
-      name: build-operator
+      name: shipwright-build
   template:
     metadata:
       labels:
-        name: build-operator
+        name: shipwright-build
     spec:
-      serviceAccountName: build-operator
+      serviceAccountName: shipwright-build-controller
       containers:
-        - name: build-operator
-          image: ko://github.com/shipwright-io/build/cmd/manager
+        - name: shipwright-build
+          image: ko://github.com/shipwright-io/build/cmd/controller
           env:
             - name: WATCH_NAMESPACE
               valueFrom:
                 fieldRef:
                   fieldPath: metadata.namespace
-            - name: BUILD_OPERATOR_LEADER_ELECTION_NAMESPACE
+            - name: BUILD_CONTROLLER_LEADER_ELECTION_NAMESPACE
               valueFrom:
                 fieldRef:
                   fieldPath: metadata.namespace
             - name: POD_NAME
               valueFrom:
                 fieldRef:
                   fieldPath: metadata.name
-            - name: OPERATOR_NAME
-              value: "build-operator"
+            - name: CONTROLLER_NAME
+              value: "shipwright-build"
           livenessProbe:
             exec:
               command:

docs/build.md

@@ -301,7 +301,7 @@ Please consider the description of the attributes under `.spec.runtime`:
 > Specifying the runtime section will cause a `BuildRun` to push `spec.output.image` twice. First, the image produced by chosen `BuildStrategy` is pushed, and next it gets reused to construct the runtime-image, which is pushed again, overwriting `BuildStrategy` outcome.
 > Be aware, specially in situations where the image push action triggers automation steps. Since the same tag will be reused, you might need to take this in consideration when using runtime-images.
 
-Under the cover, the runtime image will be an additional step in the generated Task spec of the TaskRun. It uses [Kaniko](https://github.com/GoogleContainerTools/kaniko) to run a container build using the `gcr.io/kaniko-project/executor:v0.24.0` image. You can overwrite this image by adding the environment variable `KANIKO_CONTAINER_IMAGE` to the [build operator deployment](../deploy/operator.yaml).
+Under the cover, the runtime image will be an additional step in the generated Task spec of the TaskRun. It uses [Kaniko](https://github.com/GoogleContainerTools/kaniko) to run a container build using the `gcr.io/kaniko-project/executor:v0.24.0` image. You can overwrite this image by adding the environment variable `KANIKO_CONTAINER_IMAGE` to the [build controller deployment](../deploy/controller.yaml).
 
 ## BuildRun deletion
 

docs/configuration.md

@@ -6,15 +6,15 @@ SPDX-License-Identifier: Apache-2.0
 
 # Configuration
 
-The `build-operator` is installed into Kubernetes with reasonable defaults. However, there are some settings that can be overridden using environment variables in [`operator.yaml`](../deploy/operator.yaml).
+The controller is installed into Kubernetes with reasonable defaults. However, there are some settings that can be overridden using environment variables in [`controller.yaml`](../deploy/controller.yaml).
 
 The following environment variables are available:
 
 | Environment Variable | Description |
 | --- | --- |
 | `CTX_TIMEOUT` | Override the default context timeout used for all Custom Resource Definition reconciliation operations. |
 | `KANIKO_CONTAINER_IMAGE` | Specify the Kaniko container image to be used instead of the default, for example `gcr.io/kaniko-project/executor:v1.0.1`. |
-| `BUILD_OPERATOR_LEADER_ELECTION_NAMESPACE` |  Set the namespace to be used to store the `build-operator` lock, by default it is in the same namespace as the operator itself. |
-| `BUILD_OPERATOR_LEASE_DURATION` |  Override the `LeaseDuration`, which is the duration that non-leader candidates will wait to force acquire leadership. |
-| `BUILD_OPERATOR_RENEW_DEADLINE` |  Override the `RenewDeadline`, which is the duration that the acting master will retry refreshing leadership before giving up. |
-| `BUILD_OPERATOR_RETRY_PERIOD` |  Override the `RetryPeriod`, which is the duration the LeaderElector clients should wait between tries of actions. |
+| `BUILD_CONTROLLER_LEADER_ELECTION_NAMESPACE` |  Set the namespace to be used to store the `shipwright-build-controller` lock, by default it is in the same namespace as the controller itself. |
+| `BUILD_CONTROLLER_LEASE_DURATION` |  Override the `LeaseDuration`, which is the duration that non-leader candidates will wait to force acquire leadership. |
+| `BUILD_CONTROLLER_RENEW_DEADLINE` |  Override the `RenewDeadline`, which is the duration that the acting master will retry refreshing leadership before giving up. |
+| `BUILD_CONTROLLER_RETRY_PERIOD` |  Override the `RetryPeriod`, which is the duration the LeaderElector clients should wait between tries of actions. |

docs/development/authentication.md

@@ -6,7 +6,7 @@ SPDX-License-Identifier: Apache-2.0
 
 # Understanding authentication at runtime
 
-The following document provides an introduction around the different authentication methods that can take place during an image build when using the Build operator.
+The following document provides an introduction around the different authentication methods that can take place during an image build when using the Build controller.
 
 - [Overview](#overview)
 - [Build Secrets Annotation](#build-secrets-annotation)

docs/development/testing.md

@@ -87,7 +87,7 @@ Integration tests are designed based on the following:
 
 - All significant features should have an integration test.
 - They require to have access to a Kubernetes cluster.
-- Each test generates its own instance of the build operator, namespace and resources.
+- Each test generates its own instance of the build controller, namespace and resources.
 - After test are executed, all generated resources for the particular test are removed.
 - They test all the interactions between components that have a relationship.
 - They do not test an e2e flow.

docs/metrics.md

@@ -8,7 +8,7 @@ SPDX-License-Identifier: Apache-2.0
 
 The Build component exposes several metrics to help you monitor the health and behavior of your build resources.
 
-Following build metrics are exposed at service `build-operator-metrics` on port `8383`.
+Following build metrics are exposed on port `8383`.
 
 | Name                                                 | Type      | Description                                       | Labels                                                                                                                                                                           | Status       |
 |:-----------------------------------------------------|:----------|:--------------------------------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-------------|
@@ -34,14 +34,14 @@ Environment variables can be set to use custom buckets for the histogram metrics
 | `build_buildrun_taskrun_rampup_duration_seconds`     | `PROMETHEUS_BR_RAMPUP_DUR_BUCKETS` | `0,1,2,3,4,5,6,7,8,9,10`                 |
 | `build_buildrun_taskrun_pod_rampup_duration_seconds` | `PROMETHEUS_BR_RAMPUP_DUR_BUCKETS` | `0,1,2,3,4,5,6,7,8,9,10`                 |
 
-The values have to be a comma-separated list of numbers. You need to set the environment variable for the build operator for your customization to become active. When running locally, set the variable right before starting the operator:
+The values have to be a comma-separated list of numbers. You need to set the environment variable for the build controller for your customization to become active. When running locally, set the variable right before starting the controller:
 
 ```bash
 export PROMETHEUS_BR_COMP_DUR_BUCKETS=30,60,90,120,180,240,300,360,420,480
 make local
 ```
 
-When you deploy the build operator in a Kubernetes cluster, you need to extend the `spec.containers[0].spec.env` section of the sample deployment file, [operator.yaml](../deploy/operator.yaml). Add an additional entry:
+When you deploy the build controller in a Kubernetes cluster, you need to extend the `spec.containers[0].spec.env` section of the sample deployment file, [controller.yaml](../deploy/controller.yaml). Add an additional entry:
 
 ```yaml
 [...]
@@ -74,7 +74,7 @@ export PROMETHEUS_ENABLED_LABELS=buildstrategy,namespace,build
 make local
 ```
 
-When you deploy the build operator in a Kubernetes cluster, you need to extend the `spec.containers[0].spec.env` section of the sample deployment file, [operator.yaml](../deploy/operator.yaml). Add an additional entry:
+When you deploy the build controller in a Kubernetes cluster, you need to extend the `spec.containers[0].spec.env` section of the sample deployment file, [controller.yaml](../deploy/controller.yaml). Add an additional entry:
 
 ```yaml
 [...]

docs/profiling.md

@@ -6,32 +6,32 @@ SPDX-License-Identifier: Apache-2.0
 
 # Build Controller Profiling
 
-The build operator supports a `pprof` profiling mode, which is omitted from the binary by default. To use the profiling, use the operator image that was built with `pprof` enabled.
+The build controller supports a `pprof` profiling mode, which is omitted from the binary by default. To use the profiling, use the controller image that was built with `pprof` enabled.
 
-## Enable `pprof` in the build operator
+## Enable `pprof` in the build controller
 
-In the Kubernetes cluster, edit the `build-operator` deployment to use the container tag with the `debug` suffix.
+In the Kubernetes cluster, edit the `shipwright-build-controller` deployment to use the container tag with the `debug` suffix.
 
 ```sh
 kubectl --namespace <namespace> set image \
-  deployment/build-operator \
-  build-operator="$(kubectl --namespace <namespace> get deployment build-operator --output jsonpath='{.spec.template.spec.containers[].image}')-debug"
+  deployment/shipwright-build-controller \
+  shipwright-build-controller="$(kubectl --namespace <namespace> get deployment shipwright-build-controller --output jsonpath='{.spec.template.spec.containers[].image}')-debug"
 ```
 
-## Connect `go pprof` to build operator
+## Connect `go pprof` to build controller
 
-Depending on the respective setup, there could be multiple build operator pods for high availability reasons. In this case, you have to look-up the current leader first. The following command can be used to verify the currently active leader:
+Depending on the respective setup, there could be multiple build controller pods for high availability reasons. In this case, you have to look-up the current leader first. The following command can be used to verify the currently active leader:
 
 ```sh
-kubectl --namespace <namespace> get configmap build-operator-lock --output json \
+kubectl --namespace <namespace> get configmap shipwright-build-controller-lock --output json \
   | jq --raw-output '.metadata.annotations["control-plane.alpha.kubernetes.io/leader"]' \
   | jq --raw-output .holderIdentity
 ```
 
 The `pprof` endpoint is not exposed in the cluster and can only be used from inside the container. Therefore, set-up port-forwarding to make the `pprof` port available locally.
 
 ```sh
-kubectl --namespace <namespace> port-forward <build-operator-pod-name> 8383:8383
+kubectl --namespace <namespace> port-forward <controller-pod-name> 8383:8383
 ```
 
 Now, you can setup a local webserver to browse through the profiling data.

pkg/config/config.go

@@ -31,11 +31,11 @@ const (
 	prometheusEnabledLabelsEnvVar = "PROMETHEUS_ENABLED_LABELS"
 
 	leaderElectionNamespaceDefault = "default"
-	leaderElectionNamespaceEnvVar  = "BUILD_OPERATOR_LEADER_ELECTION_NAMESPACE"
+	leaderElectionNamespaceEnvVar  = "BUILD_CONTROLLER_LEADER_ELECTION_NAMESPACE"
 
-	leaseDurationEnvVar = "BUILD_OPERATOR_LEASE_DURATION"
-	renewDeadlineEnvVar = "BUILD_OPERATOR_RENEW_DEADLINE"
-	retryPeriodEnvVar   = "BUILD_OPERATOR_RETRY_PERIOD"
+	leaseDurationEnvVar = "BUILD_CONTROLLER_LEASE_DURATION"
+	renewDeadlineEnvVar = "BUILD_CONTROLLER_RENEW_DEADLINE"
+	retryPeriodEnvVar   = "BUILD_CONTROLLER_RETRY_PERIOD"
 )
 
 var (