Skip to content

Improve CI docs #230

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
NomadXD merged 1 commit into from
Jan 16, 2026
Merged

Improve CI docs #230

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions docs/user-guide/ci/external-container-registry.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ sidebar_position: 7

This guide explains how to configure OpenChoreo to use an external container registry instead of the built-in one. External registries like Docker Hub, AWS ECR, Google Container Registry (GCR), or Azure Container Registry (ACR) can be used for storing container images.

:::info Two-Plane Architecture
:::info Architecture
OpenChoreo uses separate planes for building and running applications:
- **Build Plane**: Where images are built and pushed to the registry (requires push credentials)
- **Data Plane**: Where applications run and pull images from the registry (requires pull credentials)
Expand Down Expand Up @@ -50,7 +50,7 @@ global:
enabled: false
```

Then create custom `ClusterWorkflowTemplates` based on the [default templates](https://github.com/openchoreo/openchoreo/tree/main/install/helm/openchoreo-build-plane/templates/workflow-templates) in the OpenChoreo repository.
Then, create custom `ClusterWorkflowTemplates` based on the [default templates](https://github.com/openchoreo/openchoreo/tree/main/install/helm/openchoreo-build-plane/templates/workflow-templates) in the OpenChoreo repository.

### Step 3: Add Registry Push Credentials

Expand Down
9 changes: 6 additions & 3 deletions docs/user-guide/ci/private-repository.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,13 +16,13 @@ Create a git token with read access to your repositories.

### Step 2: Switch to Build Plane Context

If your control plane and build plane are in **separate Kubernetes clusters**, switch to the build plane cluster context. This is where workflow execution and git cloning happens.
Switch to the build plane cluster context. This is where workflow execution and git cloning happens.

```bash
kubectl config use-context <build-plane-context>
```

### Step 3: Store the Token in OpenChoreo
### Step 3: Store the Token in the Key Vault

**For Development/Testing (using fake provider):**

Expand All @@ -49,6 +49,10 @@ kubectl get clustersecretstore default -o yaml

Configure a ClusterSecretStore for your secret manager (AWS Secrets Manager, HashiCorp Vault, etc.) and store your token with key `git-token`.

:::warning
Do not change the key name `git-token`. This key is referenced by the default ComponentWorkflows during the clone step.
:::

### Step 4: Use Private Repository in Your Component

Simply reference your private repository URL in the Component spec:
Expand Down Expand Up @@ -88,7 +92,6 @@ When building from a private repository:
1. **ComponentWorkflow** defines an ExternalSecret resource that fetches your Git token from a secret backend
2. **ComponentWorkflowRun controller** creates the ExternalSecret in the Build Plane before executing the workflow
3. **Clone step** reads the token from the mounted secret, constructs an authenticated URL, and clones the repository
4. Credentials are never exposed in logs or workflow outputs

This architecture separates secret management (control plane) from build execution (build plane) while maintaining security.

Expand Down