Share
I den andra och sista delen av serien ser vi på Jenkins Workflow-plugin som en lösning för att skapa mer komplexa Jenkins-pipeliner.
Vi kommer att plocka upp var del en av serierna slutade. I del ett guidade Jeff Reifman dig genom att skapa en Jenkins-instans på Digital Ocean och skapa din första Jenkins-byggnad. Om du inte redan har läst det, föreslår jag att du gör det innan du fortsätter. Det är okej-jag ska vänta. Jag kan vara väldigt tålmodig ...
... Alla fångade upp? Bra! Nu gör vi det.
Jenkins Workflow är ett plugin för Jenkins. När en gång har installerats blir en ny objekttyp tillgänglig: ett "Workflow". Arbetsflödesprojekt kan användas för samma ändamål som vanliga "Freestyle" Jenkins-projekt, men de har också möjlighet att orkestrera mycket större uppgifter som kan spänna över flera projekt och till och med skapa och hantera flera arbetsytor i ett enda arbetsflöde. Dessutom kan all denna hantering organiseras i ett enda skript, i stället för att spridas över en samling konfigurationer, projekt och steg.
Innan vi kan börja bygga arbetsflöden måste vi installera Jenkins Workflow-plugin. Från Jenkins Dashboard, klicka Hantera Jenkins, sedan Hantera plugins. Byt till Tillgängliga fliken och söka efter "Workflow".
Markera rutan för Workflow Plugin, sedan Installera utan omstart.
Nu är här fångsten. Det finns flera plugins som heter "Workflow Plugin", så du måste repetera ovanstående steg flera gånger. Alternativt kan du också klicka på flera kryssrutor eller installera Workflow Aggregator plugin.
När "Workflow Plugin" inte längre visas i listan med tillgängliga plugins, fortsätt och starta om Jenkins genom att navigera till /omstart och klicka på Ja.
Låt oss få våra Workflow-fötter våta. Vi tar projektet Jeff upp i del ett och bygger det som ett arbetsflöde.
För att komma igång, gå till Jenkins Dashboard och klicka Nytt föremål. Namn det nya objektet "Shell Test (Workflow)" och välj Workflow typ.
Klick ok att skapa det nya projektet. Du kommer att landa på projektets konfigurationssida.
Du märker att konfigurationsalternativen skiljer sig från standard Jenkins-projekt. Det finns inte längre några alternativ att lägga till ett GitHub-repo, bygga steg eller efterbygga åtgärder. I stället heter det en ny sektion Workflow.
Inom arbetsflödesdelen är en textruta märkt Manus. Det är där du ska definiera Workflow-skriptet Jenkins kommer att köras när det initierar en byggnad av projektet.
"Vilken typ av skript?" Frågar du. Utmärkt fråga. Jenkins Workflow-plugin använder ett språk som heter Groovy för sina skript. Groovy är ett mångsidigt skriptspråk för JVM. Oroa dig inte, du behöver inte riktigt veta Groovy eller Java för att få saker att fungera. Jenkins Workflow-plugin använder en liten DSL ovanpå Groovy, och det är mycket enkelt att kombinera kommandon för att bygga upp ditt arbetsflöde.
Fortsätt och lägg till följande i manusrutan:
java nod git 'https://github.com/redhotvengeance/hello-jenkins.git' sh 'uptime'
Så vad händer här?
Först av, vi öppnar en nod blockera. Noder är där arbetsflödesåtgärder händer. När du allokerar a nod, en ny arbetsyta (ett sammanhang / en mapp) skapas. Hela koden inom nod block exekverar inom den här arbetsytan. Detta hjälper till att säkerställa att byggsteg inte förorenar varandra.
Därefter kör vi ett Git-kommando med git 'https://github.com/redhotvengeance/hello-jenkins.git'. Detta kommando klonar Git repo i vårt arbetsområde.
Slutligen berättar vi Workflow att utföra drifttid shell kommando med sh "uptime".
Klick Spara, och du kommer att tas till projektets målsida. I den vänstra menyn är en knapp märkt Bygg nu. Klicka på den för att starta en byggnad.
När byggnaden är klar klickar du på byggnaden # 1 hittades i Bygg historia sektion. Klicka sedan Konsolutgång i vänstra menyn.
Här kan vi se allt loggat medan byggnaden gjordes. Det började med att ange en nod i "Shell Test (Workflow)" arbetsytan. Sedan hämtade den Git repo. Slutligen utförde den drifttid skalskriptet, som skrivit upp servertidstidsstatistik.
Och det är allt! Vi har nu återskapat samma steg som den vanliga Jenkins-projektinställningen i del ett, förutom den här tiden som ett arbetsflöde. Låt oss nu använda samma begrepp för att göra något lite mer komplext.
Innan vi kan skapa vårt komplexa arbetsflöde, behöver vi det arbete som kommer att flöda genom det. Fake projekt (er) till undsättning!
Eftersom vi redan använder Groovy för att skripta vårt Workflow, låt oss använda Gradle för våra falska projekt. Gradle är ett byggsystem som använder Groovy (förvånande, jag vet!). För att använda Gradle måste vi installera den på vår server. SSH till din server (kolla Jeffs del ett om du behöver uppdatera ditt minne) och köra:
shell sudo apt-get installeringsgrad
Där är vi bra att gå.
Vi använder två repos i vårt nya Workflow. Den första är byggaren. Vårt byggprojekt är mycket enkelt - det har ett Gradle build-skript i det med följande kod:
groovy task createBuild << new File("built.txt").write("You cannot pass.\n")
Så vad händer här? Gradle fungerar genom att utföra "uppgifter", och Gradle build script definierar dessa uppgifter. Vi har definierat en uppgift som heter createBuild, och vad det gör är att skapa en textfil som heter built.txt med innehållet:
Du får inte passera.
Det är allt. (Jo, jag gjorde säg att det var enkelt!)
Den andra Git repo är vår förpackare. Förpackaren har också ett Gradle build-skript, men det är lite mer komplicerat:
groovy task createPackage << String packageText = "I am a servant of the Secret Fire, wielder of the flame of Anor. You cannot pass. The dark fire will not avail you, flame of Udûn. Go back to the Shadow!" String builtText = new File('built.txt').text new File("package.txt").write(packageText + "\n\n" + builtText)
De createPackage uppgiften skapar också en textfil (kallad package.txt), men det förväntar sig att använda innehåll från built.txt, som inte existerar i packarens repo. Om built.txt fanns i repo, den genererade package.txt skulle innehålla:
Jag är tjänare till den hemliga elden, wielder av Anors flamma. Du får inte passera. Den mörka elden kommer inte till nytta för dig, Utuns flamma. Gå tillbaka till skuggan!
Du får inte passera.
Om built.txt saknas, vårt createPackage uppgiften kommer att kasta ett fel.
Så varje gång vi bygger vår förpackare måste vi först springa vår byggare och göra den resulterande built.txt tillgänglig för förpackaren så att den kan skapa package.txt.
Och det är precis vad vi ska sätta upp ett Jenkins Workflow att göra!
Gå till Jenkins Dashboard, klicka Nytt föremål, namnge det "Assembler", välj Workflow, och klicka ok.
Låt oss börja skript. Först öppnar vi en nod blockera, precis som tidigare:
"java node
"
Låt oss sedan klona vårt byggarrepo:
java nod git 'https://github.com/redhotvengeance/jenkins-workflow-build.git'
Nu måste vi köra vårt Gradle build-skript för att generera built.txt fil:
java nod git 'https://github.com/redhotvengeance/jenkins-workflow-build.git' sh 'gradle createBuild'
Slutligen, låt oss se till att allt fungerar som vi förväntar oss. Vi lägger till en katt att skriva ut innehållet i built.txt fil:
Java-noden git 'https://github.com/redhotvengeance/jenkins-workflow-build.git' sh 'gradle createBuild'sh'cat'/built.txt'
Klick Spara, och börja sedan bygga. När det är klart, ta en titt på Konsolutgång.
Excellent! Vi klarar framgångsrikt kloningen, körs createBuild uppgift, och har bekräftat att innehållet i built.txt är Du får inte passera.. Nu vidare till förpackaren.
Precis som hos byggaren måste vi klona våra packagerrepo. Låt oss lägga till paketkoden:
"java nod git 'https://github.com/redhotvengeance/jenkins-workflow-build.git' sh 'gradle createBuild' sh 'katt ./built.txt'
nod git 'https://github.com/redhotvengeance/jenkins-workflow-package.git' sh 'gradle createPackage' sh 'katt ./package.txt' "
Eftersom vi inte uttryckligen skapat en ny arbetsyta, createPackage Uppgiften kommer att köras i samma arbetsyta som createBuild uppgift, vilket innebär att built.txt fil som förpackaren förväntar sig kommer att vara tillgänglig för den.
Gå vidare och Spara och Bygg nu, och sedan se Konsolutgång.
Allt gick som förväntat - vår byggare klonades och sprang, och vår förpackare klonades och sprang. Och om vi tittar på produktionen-där är det! Morgoth Balrog har varit fullständigt Gandalfd.
Krystat? Absolut.
Men ett komplext koncept är egentligen bara en massa enkla begrepp som sammanfogas. På ytan monterade vi Gandalfs tal på Khazad-dûmbroen. Men egentligen tog vi byggproduktionen från ett projekt och injicerade det i byggproduktionen från ett annat projekt.
Vad händer om istället för Gandalfs dialog var byggutgångarna exekverbara från separata kodbaser som alla behöver monteras tillsammans för den programvara som du skickar? Du använder samma arbetsflöde här: kloning, byggnad, kopiering och förpackning. Med Jenkins Workflow-plugin var det bara några rader av Groovy. Och som en bonus finns allt i ett enda skript!
Det finns också andra verktyg tillgängliga för att hantera och visualisera ett Jenkins Workflow. CloudBees erbjuder en Workflow Stage View-funktion på företagets Jenkins Platform.
Detta klipper bara ytan på vad som kan göras med Jenkins Workflow-plugin. Var noga med att kolla in de relaterade länkarna nedan för att lära dig mer.
Lycka till att ditt arbete flyter!
Accentsconagua