Merge pull request #4193 from stackitcloud/correct_kpack_links

Change pivotal/kpack to buildpacks-community/kpack

Author: danail-branekov

INSTALL.md

@@ -53,9 +53,9 @@ DockerHub allows only one private repository per free account. In case the Docke
 
 ### Kpack
 
-[Kpack](https://github.com/pivotal/kpack) is used to build runnable applications from source code using [Cloud Native Buildpacks](https://buildpacks.io/). Follow the [instructions](https://github.com/pivotal/kpack/blob/main/docs/install.md) to install the [latest version](https://github.com/pivotal/kpack/releases/latest).
+[Kpack](https://github.com/buildpacks-community/kpack) is used to build runnable applications from source code using [Cloud Native Buildpacks](https://buildpacks.io/). Follow the [instructions](https://github.com/buildpacks-community/kpack/blob/main/docs/install.md) to install the [latest version](https://github.com/buildpacks-community/kpack/releases/latest).
 
-The Helm chart will create an example Kpack `ClusterBuilder` (with the associated `ClusterStore` and `ClusterStack`) by default. To use your own `ClusterBuilder`, specify the `kpackImageBuilder.clusterBuilderName` value. See the [Kpack documentation](https://github.com/pivotal/kpack/blob/main/docs/builders.md) for details on how to set up your own `ClusterBuilder`.
+The Helm chart will create an example Kpack `ClusterBuilder` (with the associated `ClusterStore` and `ClusterStack`) by default. To use your own `ClusterBuilder`, specify the `kpackImageBuilder.clusterBuilderName` value. See the [Kpack documentation](https://github.com/buildpacks-community/kpack/blob/main/docs/builders.md) for details on how to set up your own `ClusterBuilder`.
 
 ### Contour
 
@@ -183,9 +183,9 @@ kubectl --namespace "$KORIFI_NAMESPACE" create secret generic <registry-ca-secre
 You can then specify the `<registry-ca-secret-name>` using the `containerRegistryCACertSecret`.
 
 > **Warning**
-> Kpack does not support self-signed/internal CA configuration out of the box (see [pivotal/kpack#207](https://github.com/pivotal/kpack/issues/207)).
+> Kpack does not support self-signed/internal CA configuration out of the box (see [buildpacks-community/kpack#207](https://github.com/buildpacks-community/kpack/issues/207)).
 > In order to make Kpack trust your CA certificate, you will have to inject it in both the Kpack controller and the Kpack build pods.
-> * The [`kpack-controller` `Deployment`](https://github.com/pivotal/kpack/blob/main/config/controller.yaml) can be modified to mount a `Secret` similar to the one created above: see the [Korifi API `Deployment`](https://github.com/cloudfoundry/korifi/blob/main/helm/korifi/api/deployment.yaml) for an example of how to do this.
+> * The [`kpack-controller` `Deployment`](https://github.com/buildpacks-community/kpack/blob/main/config/controller.yaml) can be modified to mount a `Secret` similar to the one created above: see the [Korifi API `Deployment`](https://github.com/cloudfoundry/korifi/blob/main/helm/korifi/api/deployment.yaml) for an example of how to do this.
 > * For the build pods you can use the [cert-injection-webhook](https://github.com/vmware-tanzu/cert-injection-webhook), configured on the `kpack.io/build` label.
 
 ## Install Korifi

controllers/config/samples/cfpackage.yaml

@@ -9,7 +9,7 @@ spec:
   type: bits
   appRef:
     name: 14dcda7d-1fa1-4a91-b437-fbdba20e8c5a # Enforced via a Validating Webhook to reject empty or non-valid appRefs/appGUID
-  source: # keeping this source block above registry gives us flexibility to support other kpack source types: https://github.com/pivotal/kpack/blob/main/docs/image.md#source-configuration
+  source: # keeping this source block above registry gives us flexibility to support other kpack source types: https://github.com/buildpacks-community/kpack/blob/main/docs/image.md#source-configuration
     registry:
       image: gcr.io/cf-relint-greengrass/cf-crd-staging-spike/packages/665a78f8-ed97-47e6-85b2-60cbcc21d5e2
       imagePullSecrets:

docs/architecture.md

@@ -15,7 +15,7 @@ Korifi is built up of the following core components:
 ### Extension Points
 Korifi includes several custom resources that serve as extension points to provide additional flexibility to operators and developers. Currently, we provide the `BuildWorkload`, `AppWorkload`, and `TaskWorkload` custom resources as interfaces that abstract away the app staging and running subsystems from the rest of the project. Platform teams (and the Korifi community in general) are welcome to implement their own controllers for these resources to support other build systems and runtimes.
 
-* **BuildWorkload Resource**: A custom resource that serves as an interface to the underlying build system used for staging applications. This resource contains all the information needed to stage an app and controller implementations communicate back via its status. The `kpack-image-builder` controller is our reference implementation for application staging that utilizes [kpack](https://github.com/pivotal/kpack) and [Cloud Native Buildpacks](https://buildpacks.io/).
+* **BuildWorkload Resource**: A custom resource that serves as an interface to the underlying build system used for staging applications. This resource contains all the information needed to stage an app and controller implementations communicate back via its status. The `kpack-image-builder` controller is our reference implementation for application staging that utilizes [kpack](https://github.com/buildpacks-community/kpack) and [Cloud Native Buildpacks](https://buildpacks.io/).
 
 
 * **AppWorkload Resource**: A custom resource that serves as an interface to the underlying runtime. This resource contains all the information needed to run an app, and controller implementations communicate back to the rest of Korifi via its status. The `statefulset-runner` controller is our reference implementation that runs apps via Kubernetes `StatefulSets`. `StatefulSets` allow us to support features of CF such as the `CF_INSTANCE_INDEX` (an ordered numeric index for each container) environment variable and APIs, but there have been talks to loosen some of this support and use `Deployments` instead.
@@ -32,7 +32,7 @@ As mentioned earlier, we aim to be loosely coupled with our dependencies and int
 
 * **cert-manager**: We use [cert-manager](https://cert-manager.io/) to generate and rotate the internal certs used for our webhooks.
 * **metrics-server**: We use [metrics-server](https://github.com/kubernetes-sigs/metrics-server) to expose app container metrics to developers.
-* **kpack**: We use [kpack](https://github.com/pivotal/kpack) and [Cloud Native Buildpacks](https://buildpacks.io/) to stage apps via the `kpack-image-builder` controller. This dependency sits behind our `BuildWorkload` abstraction and the `kpack-image-builder` controller could be replaced with alternative staging implementations.
+* **kpack**: We use [kpack](https://github.com/buildpacks-community/kpack) and [Cloud Native Buildpacks](https://buildpacks.io/) to stage apps via the `kpack-image-builder` controller. This dependency sits behind our `BuildWorkload` abstraction and the `kpack-image-builder` controller could be replaced with alternative staging implementations.
 * **Contour**: We use [Contour](https://projectcontour.io/) as our default ingress controller. Contour is a CNCF project that serves as a control plane for [Envoy Proxy](https://www.envoyproxy.io/) that provides a robust, lightweight ingress routing solution. Our `CFRoute` resources are reconciled into Gateway API `HTTPRoute` and K8s `Service` resources to implement app ingress routing. However, Contour could be substituted by any Gateway API implementation.
 
 ---