Pipeline koncept

Helm charten spring-boot-pipeline studeras enklast genom att generera en pipeline med hjälp av Helm CLI och helm template , samt läsa i Tektons egna dokumentation. Man kan även få en visuell representation via openshifts web consol.

På den här confluence-sidan beskrivs generella koncept som används och hur saker hänger ihop på en högre nivå för just spring-boot-pipeline.

Pipelinen som genereras är även beroende av definitionerna som återfinns i common pipeline repositoryt. Det som finns i detta repository är gemensamt för alla tjänster och det som genereras från helm blir unikt för varje tjänst.

Parametrar med default värden

När man genererar en pipeline med hjälp av spring-boot-pipeline chart är bland det första man ser vilka parametrar som pipelinen tar in.

Exempel:

spec:
  params:
    - default: 'git@github.com:Sundsvallskommun/api-service-simulator-server.git'
      description: Url to repository
      name: gitUrl
      type: string
    - default: main
      description: Branch to build
      name: branch
      type: string
    - default: 'false'
      description: Skip pushing build image to image repository
      name: skipImagePush
      type: string
    - default: openjdk-17-ubi8
      description: Java version
      name: javaImageStreamTag
      type: string

Parametrar som finns här är bara de som man skulle kunna tänkas vilja ändra i en manuell körning via web konsolen. Eftersom helm nyttjas skulle egentligen inga pipeline parametrar behövas alls utan allt skulle kunna hanteras genom helm (values.yaml blir parametrar som populeras i alla templates). Dock skulle det innebära att inget kan ändras vid manuell körning utan att ändra hela pipelinen. Därför har ett antal attribut valts att läggas som tekton pipline parametrar.

Genom att låta helm sätta default underlättar man manuella körningar genom att alla parametrar blir populerade till det som används vid automatisk triggning av pipeline. Denna princip bör användas för alla nya parametrar som adderas.

Triggering av pipeline

I Tektons egna dokumentation uppmanas man att skapa en eventListener per git repository. Detta skulle innebära en unik webhook url för varje repository, med brandväggsöppningar som följd. Varje eventListener skapar också en egen pod som tar resurser från klustret vilket skalar dåligt. Därför har en annan variant implementerats.

I common pipeline repot har en generell eventListener implementerats som är tänkt att hantera alla inkommande webhooks. Den triggar alla pipelines genom matchLables:

Snippet från common pipeline/github-eventlistener:

triggerSelector:
        labelSelector:
          matchLabels:
            triggerType: spring-boot-application

Varje tjänst har sina unika triggers med denna label och som sedan filtrerar om den ska köra eller inte.

Exempel från en tjänsts trigger:

apiVersion: triggers.tekton.dev/v1beta1
kind: Trigger
metadata:
  labels:
    app.kubernetes.io/instance: simulator-server-pipeline
    triggerType: spring-boot-application
  name: simulator-server-trigger
  namespace: pipelines-utvecklingsfabriken
spec:
  interceptors:
    - params:
        - name: filter
          value: >-
            body.repository.ssh_url ==
            'git@github.com:Sundsvallskommun/api-service-simulator-server.git'
            && body.ref.split('/')[2] == 'main'
      ref:
        name: cel

Om filtret släpper igenom webhooken triggas pipelinen genom en inline template:

Exempel från en tjänst trigger

Det ända som behövs knytas är workspace och ett namn då alla parametrar redan ligger i pipelinen.

Maven with cache

För att optimera byggtider har en egen maven task skapats “maven-with-cache-v1”. Detta är en kopia på de färdigdefinierade maven tasks som finns i openshift, med två tillägg.

Den plockar ut versionen från pom.xml som ett eget step mvn-version som sedan kan refereras från andra Tekton tasks.
Den sätter upp en .m2 cache i befintligt workspace.