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 Tektons egna dokumentation. Man kan även få en visuell representation via openshifts web consol.
...
Pipelinen som genereras är även beroende av definitionerna som återfinns i common pipeline repot repositoryt. Det som finns i detta repo repository är gemensamt för alla tjänster och det som genereras från helm blir unikt för varje tjänst.
...
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 innebära att inget kan ändras vid manuell körning utan att ändra hela pipelinen. Därför har ett antal attributs 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. Om Denna princip bör användas för alla nya parametrar som adderas bör därför denna princip användas.
Triggering av pipeline
I tektons 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 Därför har en annan variant implementerats.
...
Den plockar ut versionen från pom.xml som ett eget step
mvn-versionsom sedan kan refereras från andra tekton taskTekton tasks.Den sätter upp en .m2 cache i befintligt workspace.
...