CI/CD

⚙️ CI/CD Pipeline Overview

Our CI/CD pipeline is designed to provide a secure, automated, and efficient process for building and deploying applications in the IGAAWI infrastructure. Here’s how it works.

CI/CD Flow

graph LR;
    A[Git Commit] --> B[GitHub Webhook]
    B --> C[EventListener - Tekton]
    C --> D[Pipeline]
    D --> E[Build and Push]
    E --> F[Git Update]
    F --> G[Argo CD Sync]
    G --> H[Deployment]

🚀 GitOps in CI/CD: Tekton + Argo CD

In this project, we follow the GitOps methodology, where the Git repository acts as the single source of truth for both infrastructure and application configurations.

This means:

• All infrastructure and config changes happen via pull requests to Git
• Changes are automatically applied to the cluster after being committed to specific branches
• The cluster state is continuously synchronized with Git using automation tools

🛠 Tools We Use

• Tekton – runs the CI pipeline: builds, tests, pushes images, and updates the GitOps repository. ➤ Deployed in: tekton-pipelines namespace

• Argo CD – monitors Git and automatically synchronizes the cluster with the desired state defined in the repository. ➤ Deployed in: argo-cd namespace See more instruction about Argo CD and Tekton

📁 Pipeline Definitions Location

All CI/CD pipeline configurations for this project are stored in the igaawi-kubernetes-aws repository.

This includes:

• Pipeline, Task, and PipelineRun definitions for Tekton
• Trigger configurations (EventListener, TriggerBinding, TriggerTemplate)
• Namespaces, secrets, service accounts, and other related resources

Keeping pipeline manifests in Git ensures full traceability, reproducibility, and aligns with the GitOps methodology.

✅ Any update to CI/CD logic must go through Git-based workflows — ensuring review, version control, and auditability.

GitHub Webhook Trigger

When a user commits a new change into a Git repository, Tekton will start the corresponding pipeline. Each application has its own pipeline triggered by a commit to the main branch.

To ensure only relevant repositories trigger the pipeline, specific validation conditions must be met.

For backend (igaawi-api-backend):

body.ref.startsWith('refs/heads/main') &&
body.repository.html_url.startsWith('https://github.com/saritasa-nest/') &&
body.repository.ssh_url.startsWith('git@github.com:saritasa-nest/') &&
body.repository.name == 'igaawi-api-backend'

For frontend (igaawi-frontend):

body.ref.startsWith('refs/heads/main') &&
body.repository.html_url.startsWith('https://github.com/saritasa-nest/') &&
body.repository.ssh_url.startsWith('git@github.com:saritasa-nest/') &&
body.repository.name == 'igaawi-frontend'

If any of these conditions fail, the webhook event is ignored and the pipeline does not start.

Event Listener and Pipeline Execution

е

• The webhook event is handled by a Tekton EventListener, which is responsible for receiving and processing external events (such as GitHub webhooks).
• The EventListener runs in the ci namespace of the Kubernetes cluster.
• The EventListener webhook endpoint is: https://tekton-webhook.wiperinstall.rainx.com

What is an EventListener?

A Tekton EventListener is a Kubernetes resource that listens for external events and triggers pipeline executions in response.

It works as follows:

1. Receives the webhook – the EventListener runs an HTTP endpoint that receives webhook payloads (e.g., from GitHub).
2. Parses and matches the event – using TriggerBinding and TriggerTemplate, it extracts data and defines how to launch a pipeline.
3. Starts a pipeline – if the event is valid, it creates a new PipelineRun, which triggers the CI/CD logic.

This decoupled architecture makes pipelines reusable, composable, and easier to maintain.

Tekton Pipeline Steps

graph TD;
    A[git-clone] --> B[build]
    B --> C[gitops]
    C --> D[deploy]

• git-clone - Clones the application repository to retrieve the latest source code.
• build - Builds a Docker image using the buildpack.
• gitops - Updates the GitOps repository with the new image tag.
• deploy - Deployment is handled by Argo CD.

🛠 Tekton CLI (tkn)

You can use tkn cli tool for manage pipelines.

tkn is the official command-line interface for interacting with Tekton Pipelines. It allows you to easily manage pipelines, trigger them, view logs, and stop running tasks directly from your terminal.

📋 Common tkn Commands

🔍 List running pipeline runs

tkn pr list -n ci

-n ci specifies that you’re working in the ci namespace.

📄 View details of a specific PipelineRun

tkn pr describe <pipeline-run-name> -n ci

📦 View logs for a PipelineRun

tkn pr logs <pipeline-run-name> -n ci

Or stream logs in real time:

tkn pr logs <pipeline-run-name> -f -n ci

🛑 Stop a running PipelineRun

kubectl delete pipelinerun <pipeline-run-name> -n ci

Or via tkn:

tkn pr delete <pipeline-run-name> -n ci

See more instruction about tekton in the official documentation

GitHub Authentication via Tekton Bot

Authentication to GitHub from Tekton pipelines is performed using a GitHub App — igaawi-tekton-bot.

Unlike Personal Access Tokens (PATs), GitHub Apps provide:

• Fine-grained permissions scoped to specific repositories
• No expiration tied to a user account — the app is organization-level
• Audit trail — all actions are attributed to the bot application

How it works

1. The GitHub App has an application ID (3927587) and an installation ID (137118458).
2. A private key is stored as a Kubernetes secret (tekton-bot-github-app-credentials) in the ci namespace.
3. During the github-auth-token pipeline step, the bot generates a short-lived installation access token (expires in 300 seconds) using the private key.
4. This token is used for all subsequent Git operations (cloning, pushing to gitops repo, setting commit statuses).

The configuration is defined in values.backend.ci.yaml and values.frontend.ci.yaml:

- name: github_auth
  value:
    application_name: igaawi-tekton-bot
    application_url: https://github.com/organizations/saritasa-nest/settings/apps/igaawi-tekton-bot
    application_installation_url: https://github.com/organizations/saritasa-nest/settings/installations/137118458
    application_id: "3927587"
    installation_id: "137118458"
    credentials_secret: tekton-bot-github-app-credentials
    private_key_path: private_key
    auth_token_expiration_seconds: "300"
    github_api_url: https://api.github.com

Skipping Pipeline Workflows with /tekton-ignore

The pipeline supports on-demand skipping of specific workflows via a special command in the Git commit message.

Usage

Add /tekton-ignore followed by the workflow names to your commit message:

feat: hotfix for wiper recognition

/tekton-ignore osv-scanner

You can skip multiple workflows by listing them comma-separated:

/tekton-ignore security,osv-scanner

How it works

1. The CEL interceptor in the EventListener parses the commit message looking for the /tekton-ignore command.
2. It extracts the workflow names and filters them against the allowed whitelist.
3. The detect-tekton-ignore task emits an array result used in when conditions of downstream tasks, so they are skipped for this run.
4. Only workflows from the whitelist can be skipped — any other names are silently discarded.

Configuration

The ignore feature is configured per-component in values.backend.ci.yaml:

build:
  ignore:
    allowedUsers:
      - AndyGreenwell94
      - dmitry-mightydevops
      - udaltsovra
    skipCommand: /tekton-ignore
    skipWorkflowsAllowed:
      - security
      - osv-scanner

• allowedUsers — only these GitHub usernames (from body.pusher.name) can use the command. If the pusher is not in the list, the command is logged and discarded — all workflows run as usual.
• skipCommand — the marker prefix to look for in the commit message.
• skipWorkflowsAllowed — whitelist of workflow names that can be skipped. Any word not in this list is silently dropped by the CEL filter, so developers cannot skip arbitrary tasks.

Image Push and Git Update

• After building, the image is pushed to Amazon ECR.
• The image tag (e.g., a Git commit SHA) is written back to the GitOps repository to reflect the latest version.

Deployment via Argo CD

• Argo CD continuously monitors the GitOps repository.
• When it detects a change (e.g., updated image tag), it automatically syncs the environment.
• This results in the application being updated and deployed in the target Kubernetes cluster.