1. Prepare the Application and Environment
Prepare two small repositories and the access needed for a manual build. At the end of this tutorial, you will have source code to build and a completed environment checklist. No application deployment or release approval is needed yet.
Prerequisites: complete the quick start and have an administrator available for the platform-owned steps below.
TOC
1. Administrator: Prepare the CI EnvironmentMirror Images and Configure TrustSelect Connectors Without Copying Credentials2. Developer: Create Two Minimal Repositories3. Record the Run Configuration4. Administrator: Prepare Later Stages When NeededCheckpoint1. Administrator: Prepare the CI Environment
Use a new practice namespace, for example cicd-tutorial, as
<pipeline-namespace>. Replace placeholders consistently in the examples; do
not change your global kubectl context to a production namespace.
See ArtifactHub Shim installation and Hub resolver for catalog setup.
The examples resolve git-clone:0.9, nodejs:0.1, golang:0.1, and
buildah:0.10 from catalog: catalog, with type: artifact and kind: task.
Confirm those versions exist in your installed snapshot.
The default catalog Buildah Task requires usable non-root user namespaces.
If the nodes disable them, an administrator must select an approved alternative
Task and any required namespace exception. Replacing only builderImage does
not change the Task's security context. Do not disable Pod Security controls
just to make the tutorial run. See
Pod Security Restricted.
Mirror Images and Configure Trust
Fill the <internal-...-image> placeholders in the Pipeline examples and
Containerfiles with approved internal references pinned by digest. Mirror the
catalog tool images, which may include helper programs, not just plain
Node.js or Go base images. The Node.js example needs version 22 or later; the
Go example needs version 1.23 or later.
Task Pods and node image pullers must both reach and trust the registry. An address that works only from inside a Pod is not sufficient for a Deployment image. Configure internal CA trust and private-image pull credentials using your platform's normal workflow. Keep TLS verification enabled.
The application has no third-party dependencies. Its first CI runs do not require a package Connector. For a real project, mirror packages and use an internal NPM or Go proxy before adding dependencies. Do not enable public package access as a workaround in an air-gapped environment.
Select Connectors Without Copying Credentials
Open the platform's Connector management page and select or create the Git and staging OCI Connectors. Verify their Ready state, endpoint, repository permissions, and trust configuration. Record only their names and namespace in the Pipeline examples.
See Git Connector and OCI Connector. Credentials stay in Connector-backed Secrets, not Pipeline parameters.
2. Developer: Create Two Minimal Repositories
Create empty internal Git repositories for frontend and backend, each with
a main branch. Copy the corresponding example below to the repository root.
The files use only the Node.js and Go standard libraries, so no public package
service is required.
package.json:
The Node.js repository contains package.json, server.mjs,
server.test.mjs, build.mjs, index.html, and Containerfile. The Go
repository contains go.mod, cmd/server/main.go, and Containerfile.
Do not nest either application under an extra directory. The CI Tasks run from
the repository root.
Replace the Containerfile base-image placeholders, then commit and push the
source. Record each clone URL and full commit SHA. Do not commit dist/,
bin/, local credentials, or platform configuration files to the application
repositories.
The frontend serves a page on port 8080 and requests /api/message. The Go
backend serves that API and reads APP_MESSAGE from its environment. Both
components provide /readyz and /healthz.
If you have Node.js and Go locally, run the checks shown in tutorial 2. You can also perform those checks in the CI Tasks.
3. Record the Run Configuration
Use the Pipeline and Run Template examples in tutorial 2 to fill the placeholders. Keep the following values fixed for each component:
The source Workspace uses volumeClaimTemplate: Tekton provisions a new PVC
for each PipelineRun. Never bind all runs to one fixed source PVC; one clone
could overwrite another run's files. An emptyDir works for a cache inside one
Task Pod, but cannot pass source files from the clone Task to the build Task.
The Integration annotation associates Git and OCI Connector interfaces with Task parameters and Workspaces. Keep it on both the Pipeline and the generated PipelineRun. Use the provided mappings initially; consult Pipeline Integration when adapting them to another Task.
4. Administrator: Prepare Later Stages When Needed
Do not block the first CI run on these release features:
The workload manifest in tutorial 4 contains a ConfigMap, two Deployments, two
Services, and an Ingress. The Deployments have readiness and liveness probes,
resource requests and limits, and non-root security settings. The Ingress
routes / to the frontend and /api to the backend. The pull and TLS Secrets
must already exist; their values are intentionally not included.
Prepare the values now, but apply the workload in tutorial 4, after CI has produced the two initial image digests. A Kubernetes Connector gives Tasks deployment access; it does not replace the nodes' registry pull credentials.
Checkpoint
Confirm both repositories contain the minimal source at their roots, the Git and OCI Connectors are Ready, and the CI identity, catalog, images, and storage are available. Only the files for later stages should still contain unresolved placeholders.
Next: Build and run component CI.