The Goal

My goal was to create a platform that was easily deployed, contained reusable components, and provided visual insight into the processes. My requirements for this were:

• Easy bootstrapping of a cluster
• Reusable pipeline components
• Dashboards

Easy Bootstrapping

Because ArgoCD doesn't have an easy way to bootstrap a cluster, I used FluxCD to do it. In the folder cluster/base/, are the manifests used to bootstrap the cluster.

• kustomizations/ contains the list of workloads that will be initially deployed on the cluster.

  See cluster/base/kustomizations/kustomization.yaml for a list.

• flux-system/ contains the FluxCD manifests used to install Flux.

Reusable Pipeline Components

A catalog of reusable Tekton resources can be found here https://github.com/tektoncd/catalog

There are several components, some would say a lot, that go into a Tekton pipeline. Which is why one of my goals was to make as many of them reusable. However, it can be thought of in a sort of order of operations.

• EventListener (https://tekton.dev/docs/triggers/eventlisteners/)
• TriggerBinding (https://tekton.dev/docs/triggers/triggerbindings/)
• TriggerTemplate (https://tekton.dev/docs/triggers/triggertemplates/)
• PipelineRun (https://tekton.dev/docs/pipelines/pipelineruns/)
• Pipeline (https://tekton.dev/docs/pipelines/pipelines/)
• Task (https://tekton.dev/docs/pipelines/tasks/)

I'll describe the main goals of each and a bit about how I made them reusable.

EventListener

The Event Listener runs as a workload in the cluster and receives incoming events, for example from a webhook. It's also responsible for defining a TriggerBinding and TriggerTemplate.

apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: remix-jokes-el
spec:
  serviceAccountName: tekton-triggers-admin
  triggers:
    - bindings:
        - ref: remix-jokes-tb
      template:
        ref: remix-jokes-tt

Trigger Binding

The Trigger Binding extracts fields from the incoming event and assigns them to params.

apiVersion: triggers.tekton.dev/v1beta1
kind: TriggerBinding
metadata:
  name: remix-jokes-tb
spec:
  params:
    - name: git-app-repo-url
      value: $(body.repository.url)
    - name: git-app-repo-revision
      value: main

Trigger Template

A Trigger Template is a blueprint for a resource such as a PipelineRun. It receives params from the TriggerBinding, allowing them to be passed down to the PipelineRun and, in turn, the rest of the components.

apiVersion: triggers.tekton.dev/v1alpha1
kind: TriggerTemplate
metadata:
  name: remix-jokes-tt
spec:
  params:
    - name: git-app-repo-url
      description: The git repository URL for the application.
    - name: git-app-repo-revision
      description: The git revision for the application.

  resourcetemplates:
    - apiVersion: tekton.dev/v1beta1
      kind: PipelineRun
      metadata:
        generateName: buildpack-test-pr-
        namespace: tekton-argocd-example
        labels:
          pipeline: tekton
          deploy: argocd
        annotations:
          argocd.argoproj.io/compare-options: IgnoreExtraneous
      spec:
        workspaces:
          - name: source-workspace
            subPath: source
            persistentVolumeClaim:
              claimName: buildpacks-source-pvc
          - name: cache-workspace
            subPath: cache
            persistentVolumeClaim:
              claimName: buildpacks-source-pvc
        params:
          - name: image
            value: stiforr/buildback-test
          - name: argocdServer
            value: stiforr.com
          - name: applicationName
            value: buildpack-test
          - name: dockerImage
            value: remix-jokes
          - name: dockerNamespace
            value: stiforr
          - name: git-app-repo-url
            value: $(tt.params.git-app-repo-url)
        serviceAccountName: pipeline-sa
        pipelineRef:
          name: buildpacks-test-pipeline

Note the use of generateName: buildpack-test-pr- in the PipelineRun. This resource is generated dynamically, so no two PipelineRuns will have the same name.

argocd.argoproj.io/compare-options: IgnoreExtraneous prevents argo from getting upset when these PipelineRuns are generated but are not part of the repo.

Pipeline Run

The Pipeline Run is generated by the TriggerTemplate, takes in the params from the TriggerTemplate, and refers to a Pipeline. This is the most useful resource to make reusable.

You can see the PipelineRun in the TriggerTemplate under resourceTemplates:. Here we define workspaces, params, a serviceAccountName, and a pipelineRef. I'll let the Tekton docs do the explaining for these resources.

Workspaces

(https://tekton.dev/docs/pipelines/workspaces/)

Workspaces can serve the following purposes:

• Storage of inputs and/or outputs
• Sharing data among Tasks
• A mount point for credentials held in Secrets
• A mount point for configurations held in ConfigMaps
• A mount point for common tools shared by an organization
• A cache of build artifacts that speed up jobs

Params

Params contain a name, a value, and an optional description.

Service Account Name

If you need to use secrets in your Pipeline, you'll need to give access to them. You would create the secrets and specify them in the ServiceAccount.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: pipeline-sa
secrets:
  - name: basic-docker-user-pass
  - name: basic-git-app-repo-user-pass

You can execute the Pipeline in your PipelineRun with a specific set of credentials by specifying a ServiceAccount object name in the serviceAccountName field in your PipelineRun definition. If you do not explicitly specify this, the TaskRuns created by your PipelineRun will execute with the credentials specified in the configmap-defaults ConfigMap. If this default is not specified, the TaskRuns will execute with the default service account set for the target namespace.

Pipeline Ref

(https://tekton.dev/docs/pipelines/pipelineruns/#specifying-the-target-pipeline)

You must specify the target Pipeline that you want the PipelineRun to execute, either by referencing an existing Pipeline definition, or embedding a Pipeline definition directly in the PipelineRun.

To specify the target Pipeline by reference, use the pipelineRef field:

pipelineRef:
  name: buildpacks-test-pipeline

Dashboards

I use ArgoCD's built in dashboard to specifically monitor the Pipelines and the apps they deploy. The Tekton Dashboard is also used to monitor the Pipelines.

Thanks!

If you made it this far, thanks! I hope this helps clarify how Tekton and GitOps can be used to automate your workflows and give your developers more power in your infrastructure.