Share
I denne andre og siste delen av serien ser vi på Jenkins Workflow-plugin som en løsning for å sette opp mer komplekse Jenkins rørledninger.
Vi plukker opp hvor del en av seriene sluttet. I første del guidet Jeff Reifman deg gjennom å sette opp en Jenkins-forekomst på Digital Ocean og skape din første Jenkins-bygning. Hvis du ikke allerede har lest det ennå, foreslår jeg at du gjør det før du fortsetter. Det er greit, jeg venter. Jeg kan være veldig tålmodig ...
... Alle fanget opp? Flott! La oss gjøre dette.
Jenkins Workflow er et plugin for Jenkins. Når det er installert, blir en ny elementtype tilgjengelig: en "Workflow". Arbeidsflytprosjekter kan brukes til samme formål som vanlige "Freestyle" Jenkins-prosjekter, men de har også mulighet til å orkestrere mye større oppgaver som kan spore flere prosjekter, og til og med lage og administrere flere arbeidsområder i en enkelt arbeidsflyt. I tillegg kan all denne ledelsen bli organisert i et enkelt skript, i stedet for å spre seg over en samling konfigurasjoner, prosjekter og trinn.
Før vi kan begynne å bygge arbeidsflyter, må vi installere Jenkins Workflow-plugin. Fra Jenkins Dashboard, klikk Administrer Jenkins, deretter Administrer plugger. Bytt til Tilgjengelig kategorien og søk etter "Workflow".
Merk av for Workflow Plugin, deretter Installer uten omstart.
Nå er her fangsten. Det er flere plugins kalt "Workflow Plugin", så du må gjenta trinnene ovenfor flere ganger. Alternativt kan du også klikke på flere avmerkingsbokser eller installere Workflow Aggregator plugin.
Når "Workflow Plugin" ikke lenger vises i listen over tilgjengelige plugins, så fortsett og start Jenkins ved å navigere til /omstart og klikk Ja.
La oss få våre Workflow-føtter våte. Vi tar prosjektet Jeff opp i del ett og bygger det som en arbeidsflyt.
For å komme i gang, gå til Jenkins Dashboard og klikk Ny gjenstand. Navngi det nye elementet "Shell Test (Workflow)", og velg arbeidsflyt type.
Klikk OK å skape det nye prosjektet. Du lander på prosjektets konfigurasjonsside.
Du vil legge merke til at konfigurasjonsalternativene er forskjellige fra standard Jenkins-prosjekter. Det er ikke lenger noen muligheter for å legge til en GitHub repo, bygge trinn eller post-build handlinger. I stedet er det en ny seksjon som heter arbeidsflyt.
Innenfor Workflow-delen er en tekstboks merket Manus. Det er her du skal definere Workflow-skriptet Jenkins vil kjøre når det initialiserer en konstruksjon av prosjektet.
"Hva slags script?" Spør du. Utmerket spørsmål. Jenkins Workflow-plugin bruker et språk som heter Groovy for sine skript. Groovy er et allsidig skriptspråk for JVM. Ikke bekymre deg, du trenger ikke virkelig å vite Groovy eller Java for å få ting til å fungere. Jenkins Workflow-plugin bruker en liten DSL på toppen av Groovy, og det er veldig enkelt å kombinere kommandoer for å bygge ut prosjektprosjektet ditt.
Gå videre og legg til følgende i skriptboksen:
java node git 'https://github.com/redhotvengeance/hello-jenkins.git' sh 'oppetid'
Så hva skjer her?
Først av, åpner vi en node blokkere. Noder er der arbeidsflythandlinger skje. Når du tildeler en node, et nytt arbeidsområde (en kontekst / mappe) er opprettet. Alle koden i node blokkere kjører innenfor det arbeidsområdet. Dette bidrar til at byggestrømmer ikke forurenser hverandre.
Deretter kjører vi en Git-kommando med git 'https://github.com/redhotvengeance/hello-jenkins.git'. Denne kommandoen kloner Git repo i arbeidsområdet vårt.
Til slutt forteller vi at Workflow skal utføre oppetid shell kommandoen med sh 'oppetid'.
Klikk Lagre, og du blir tatt til prosjektets destinasjonsside. I venstre meny er en knapp merket Bygg nå. Klikk på den for å slå av en bygning.
Når bygningen er ferdig, klikk på bygg #1 funnet i Bygg historie seksjon. Klikk deretter Konsollutgang i venstre meny.
Her kan vi se alt logget mens bygningen ble utført. Det startet ved å tildele en knutepunkt i "Shell Test (Workflow)" arbeidsområdet. Så hentet Git repo. Til slutt utførte den oppetid shell script, som trykte server oppetid statistikk.
Og det er det! Vi har nå gjenskapt de samme trinnene som det vanlige Jenkins-prosjektoppsettet i del ett, bortsett fra denne gangen som en arbeidsflyt. La oss nå bruke disse samme konseptene til å gjøre noe litt mer komplekst.
Før vi kan skape vår komplekse arbeidsflyt, trenger vi arbeidet som vil strømme gjennom det. Falske prosjekt (er) til redning!
Siden vi allerede bruker Groovy til å skanne arbeidsflyten, la oss bruke Gradle til våre falske prosjekter. Gradle er et byggesystem som bruker Groovy (overraskende, jeg vet!). For å bruke Gradle må vi installere den på vår server. SSH til serveren din (sjekk ut Jeffs del 1 hvis du trenger å oppdatere minnet) og kjøre:
shell sudo apt-get installasjonsgrad
Det er godt å gå.
Vi bruker to repos i vår nye Workflow. Den første er byggeren. Vårbyggerprosjektet er veldig enkelt - det har et Gradle build-skript i det med følgende kode:
groovy oppgave createBuild << new File("built.txt").write("You cannot pass.\n")
Så hva skjer her? Gradle fungerer ved å utføre "oppgaver", og Gradle build-skriptet definerer disse oppgavene. Vi har definert en oppgave som heter createBuild, og hva det gjør er å lage en tekstfil kalt built.txt med innholdet:
Du kan ikke passere.
Det er det. (Vel, jeg gjorde si det var enkelt!)
Den andre Git repo er vår pakker. Pakken har også et Gradle build-skript, men det er litt mer komplekst:
groovy oppgave 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 Oppgave oppretter også en tekstfil (kalt package.txt), men det forventer å bruke innhold fra built.txt, som ikke finnes i pakkerens repo. Hvis built.txt eksisterte i repo, den genererte package.txt vil inneholde:
Jeg er en tjener av den hemmelige ilden, wielder av Anors flamme. Du kan ikke passere. Den mørke ilden vil ikke benytte deg, Ukens flamme. Gå tilbake til skyggen!
Du kan ikke passere.
Hvis built.txt mangler, vår createPackage oppgaven vil kaste en feil.
Så hver gang vi bygger vår pakker, må vi først kjøre vår byggmester og gjøre den resulterende built.txt tilgjengelig for pakkeren slik at den kan skape package.txt.
Og det er akkurat det vi skal sette opp en Jenkins Workflow å gjøre!
Gå til Jenkins Dashboard, klikk Ny gjenstand, navnet "Assembler", velg arbeidsflyt, og klikk OK.
La oss starte skripting. Først åpner vi opp en node blokkere, akkurat som før:
"java node
"
Neste, la oss klone vår builder repo:
java node git 'https://github.com/redhotvengeance/jenkins-workflow-build.git'
Nå må vi kjøre vår Gradle build script for å generere built.txt fil:
java node git 'https://github.com/redhotvengeance/jenkins-workflow-build.git' sh 'gradle createBuild'
Til slutt, la oss sørge for at alt fungerer som vi forventer det. Vi legger til en katt å skrive ut innholdet i built.txt fil:
java node git 'https://github.com/redhotvengeance/jenkins-workflow-build.git' sh 'gradle createBuild' sh 'katt ./built.txt'
Klikk Lagre, og så start en bygg. Når det er gjort, ta en titt på Konsollutgang.
Utmerket! Vi klarte kloning av repoen, kjører createBuild oppgave, og har bekreftet at innholdet i built.txt er Du kan ikke passere.. Nå på pakken.
På samme måte som hos byggeren må vi klone vår pakkeres repo. La oss legge til pakkekoden:
"java node git 'https://github.com/redhotvengeance/jenkins-workflow-build.git' sh 'gradle createBuild' sh 'katt ./built.txt'
node git 'https://github.com/redhotvengeance/jenkins-workflow-package.git' sh 'gradle createPackage' sh 'cat./package.txt' "
Siden vi ikke opprettet et nytt arbeidsområde eksplisitt, vil createPackage oppgaven vil kjøre i samme arbeidsområde som createBuild oppgave, noe som betyr at built.txt fil som pakkeren forventer vil være tilgjengelig for den.
Gå videre og Lagre og Bygg nå, og så se Konsollutgang.
Alt gikk som forventet - vår byggmester ble klonet og løp, og vår pakker ble klonet og løp. Og hvis vi ser på utgangen-det er det! Morgoth Balrog har vært fullstendig Gandalfd.
Contrived? Mest sannsynlig.
Men et komplekst konsept er egentlig bare en haug med enkle konsepter mashed sammen. På overflaten satt vi sammen Gandalfs tale på Khazad-dûm-broen. Men egentlig tok vi byggproduksjonen fra ett prosjekt og injiserte det inn i byggproduksjonen fra et annet prosjekt.
Hva om i stedet for Gandalfs dialog, var byggeutgangene kjørbare fra separate kodebaser som alle må samles sammen for programvaren du sender? Du bruker den samme arbeidsflyten vi satt opp her: kloning, bygging, kopiering og emballasje. Med Jenkins Workflow-plugin tok alt det som var noen linjer med Groovy. Og som en bonus finnes alt i et enkelt skript!
Det er også andre verktøy tilgjengelig for å hjelpe til med å administrere og visualisere en Jenkins Workflow. CloudBees tilbyr en arbeidsflytfasevisning på sin virksomhet Jenkins Platform.
Dette skraper bare overflaten av det som kan gjøres med Jenkins Workflow-plugin. Husk å sjekke ut de tilhørende koblingene nedenfor for å lære mer.
Lykke til å få jobben flyter!
Accentsconagua