From 6dd0f688d532580d1d429027110203b97abd28e7 Mon Sep 17 00:00:00 2001 From: Adam Cmiel Date: Tue, 22 Oct 2024 11:32:39 +0200 Subject: [PATCH 1/3] Clarify setting Maintainer role for GL token If the gitlab instance supports it, it is not optional. Signed-off-by: Adam Cmiel --- .../ROOT/pages/how-tos/configuring/creating-secrets.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/modules/ROOT/pages/how-tos/configuring/creating-secrets.adoc b/docs/modules/ROOT/pages/how-tos/configuring/creating-secrets.adoc index 48d2a052..552a8047 100644 --- a/docs/modules/ROOT/pages/how-tos/configuring/creating-secrets.adoc +++ b/docs/modules/ROOT/pages/how-tos/configuring/creating-secrets.adoc @@ -59,7 +59,7 @@ When building content from GitHub, you will need to install an application for P . In GitLab select your avatar, then select **Edit profile** > **Access Tokens** > **Add new token**. . Select the following scopes: `api`, `read_repository`, and `write_repository`. -. Optional: If your GitLab instance supports setting token role, set a role to `Maintainer`. +. If your GitLab instance supports setting token roles, set the role to `Maintainer`. . Select **Create personal access token**. . Add a token to your {ProductName} workspace by running the `kubectl create` command and creating a new YAML file with a secret: From e7e6166f00a114e66ed57b391c4cd06f45650313 Mon Sep 17 00:00:00 2001 From: Adam Cmiel Date: Tue, 22 Oct 2024 11:33:48 +0200 Subject: [PATCH 2/3] Remove -tenant suffix from namespace placeholder It's a placeholder for the namespace name, those already contain the -tenant suffix. If it was a placholder for the *workspace* name, the suffix would make sense. Other examples on this page don't add the suffix either. Signed-off-by: Adam Cmiel --- .../ROOT/pages/how-tos/configuring/creating-secrets.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/modules/ROOT/pages/how-tos/configuring/creating-secrets.adoc b/docs/modules/ROOT/pages/how-tos/configuring/creating-secrets.adoc index 552a8047..39e3dbf5 100644 --- a/docs/modules/ROOT/pages/how-tos/configuring/creating-secrets.adoc +++ b/docs/modules/ROOT/pages/how-tos/configuring/creating-secrets.adoc @@ -102,7 +102,7 @@ apiVersion: v1 kind: Secret metadata: name: pipelines-as-code-secret - namespace: -tenant + namespace: labels: appstudio.redhat.com/credentials: scm appstudio.redhat.com/scm.host: # for example, gitlab.com From 97669cbe426974f2cf65d408e63ceafd2767a061 Mon Sep 17 00:00:00 2001 From: Adam Cmiel Date: Tue, 22 Oct 2024 13:50:23 +0200 Subject: [PATCH 3/3] Fix example RP for tenant release pipelines The pipelineRef and serviceAccountName field need to be nested under `pipeline` now Signed-off-by: Adam Cmiel --- .../releasing/tenant-release-pipelines.adoc | 23 ++++++++++--------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/docs/modules/ROOT/pages/advanced-how-tos/releasing/tenant-release-pipelines.adoc b/docs/modules/ROOT/pages/advanced-how-tos/releasing/tenant-release-pipelines.adoc index 53b96fb3..6830a108 100644 --- a/docs/modules/ROOT/pages/advanced-how-tos/releasing/tenant-release-pipelines.adoc +++ b/docs/modules/ROOT/pages/advanced-how-tos/releasing/tenant-release-pipelines.adoc @@ -3,7 +3,7 @@ The usual release process in {ProductName} involves two different teams: a *Development team* and a *Managed environment team* as described in xref:/advanced-how-tos/releasing/index.adoc[Releasing an application]. But, sometimes the Development team wants to release their software to some destination that is directly under their control, using their own secrets, without depending on a Managed environment team. In {ProductName} we call this model a *tenant release pipeline*. It's a release pipeline that runs in the tenant namespace of the Development team, rather than in that of the Managed environment team. -The gist here is that you are going to follow the regular instructions to xref:/advanced-how-tos/releasing/create-release-plan.adoc[create a ReleasePlan], but you will omit the `target` and specify the `pipelineRef` directly on your `ReleasePlan`. +The gist here is that you are going to follow the regular instructions to xref:/advanced-how-tos/releasing/create-release-plan.adoc[create a ReleasePlan], but you will omit the `target` and specify the `pipeline` directly on your `ReleasePlan`. .*Prerequisites* @@ -43,16 +43,17 @@ spec: - name: demo-component-2 repository: registry/destination-image-repository-2 tags: [latest] - pipelineRef: <.> - resolver: git - params: - - name: url - value: "https://github.com/konflux-ci/release-service-catalog.git" - - name: revision - value: production - - name: pathInRepo - value: "pipelines/push-to-external-registry/push-to-external-registry.yaml" - serviceAccont: appstudio-pipeline <.> + pipeline: + pipelineRef: <.> + resolver: git + params: + - name: url + value: "https://github.com/konflux-ci/release-service-catalog.git" + - name: revision + value: production + - name: pathInRepo + value: "pipelines/push-to-external-registry/push-to-external-registry.yaml" + serviceAccountName: appstudio-pipeline <.> ---- +