PR automation custom resources

You can use our CRD toolkit to generate new PR Automation flows easily. This can be as simple as generating pull requests for upgrading to a new kubernetes version in terraform, or it can involve more complex workflows. In this guide, we'll show how you can use it to provide self-service developer workspaces, a pretty common usecase for a lot of enterprises.

Defining Templates

Most of the PR automation works off of Shopify's Liquid templating engine. It's a well-documented, widely used templating library that frankly is a bit nicer than go's builtin text/template library.

For this example there are a few templates that are worth mentioning:

in templates/service.yaml.liquid:

apiVersion: deployments.plural.sh/v1alpha1
kind: ServiceDeployment
metadata:
  name: {{ context.name }}
  namespace: infra
spec:
  namespace: {{ context.name }}
  git:
    folder: workspaces
    ref: main
  repositoryRef:
    kind: GitRepository
    name: infra
    namespace: infra
  configurationRef:
    name: mottmac-pull-creds
    namespace: infra
  helm:
    version: "0.x.x"
    chart: workloads
    valuesFiles:
    - {{ context.name }}.yaml
    repository:
      namespace: infra
      name: workloads
  clusterRef:
    kind: Cluster
    name: mgmt
    namespace: infra

and workspace.yaml.liquid:

cluster: { { context.cluster } }
gitRepository: { { context.repo } }

access:
  write:
    - groupName: { { context.group } }

workloads: { { context.workloads } }

The first just generates a ServiceDeployment CRD (if you aren't familiar with this, feel free to look at the docs for the Plural operator) that will ultimately create the workspace service. The second is meant to define the helm values file for that service. The variables in context will be user specifed, and you can see it also takes a list of workloads that will be the individual components spawned by that service -- the workspace is in fact an app-of-apps.

PR Automation Spec