Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Current »

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 repot. Det som finns i detta repo ä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är att inget kan ändras vid manuell körning utan att ändra hela pipelinen. Därför har ett antal attributs 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. Om nya parametrar adderas bör därför denna princip användas.

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. Istället 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

template:
    spec:
      resourcetemplates:
        - apiVersion: tekton.dev/v1beta1
          kind: PipelineRun
          metadata:
            generateName: simulator-server-
          spec:
            pipelineRef:
              name: simulator-server
            serviceAccountName: pipeline
            workspaces:
              - name: source-workspace
                persistentVolumeClaim:
                  claimName: pvc-simulator-server-pipeline
              - name: maven-settings
                secret:
                  secretName: settings-mvn

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.

  1. Den plockar ut versionen från pom.xml som ett eget step mvn-version som sedan kan refereras från andra tekton task.

  2. Den sätter upp en .m2 cache i befintligt workspace.

  • No labels