Skapa dynamiska parametrar i Jenkins-jobbet, eller hur man gör din uppgift användarvänlig

God eftermiddag, Habr!

Idag skulle jag vilja dela med mig av ett av sätten att använda Active Choices Plugin för att göra uppgiften i Jenkins ett mer enhetligt och användarvänligt sätt.

Introduktion

Akronymen DevOps är sedan länge inte något nytt för IT-gemenskapen. Många associerar frasen "göra DevOps" med en slags magisk knapp som, när den trycks ned, automatiskt omvandlar applikationskoden till en distribuerad och testad applikation (det är mer komplicerat, men låt oss abstrahera från alla processer).

Så, vi har fått i uppdrag att skapa en sådan magisk knapp så att administratörer kan distribuera applikationen med ett enda klick. Det finns olika sätt att genomföra denna uppgift: allt från att skriva en bot för någon av meddelandetjänsterna till att utveckla en separat applikation. Målet är dessvärre detsamma – att göra start av bygg och distribution av applikationen så transparent och användarvänlig som möjligt.

I vårt fall kommer vi att använda Jenkins.

Uppgift

Skapa ett användarvänligt Jenkins-jobb som kommer att starta bygg och (eller) distribuera den valda mikrotjänsten av en viss version.

Indata

Vi har flera repository där kildekoden för olika mikrotjänster ligger.

Definiera parametrar

Indata till vårt jobb ska bestå av följande parametrar:

1. URL till repository med koden för mikrotjänsten som vi vill bygga och distribuera när jobbet körs.
2. ID för commit som byggprocessen ska utgå ifrån.

SOM DET ÄR

Det enklaste sättet att utföra uppgiften är att skapa två parametrar av typen String.

I det här fallet måste användaren manuellt ange sökvägen till repositoryn och commit-id, vilket, medge, inte är särskilt bekvämt.

AS TO BE

Nu ska vi prova en annan typ av parametrar för att se alla dess fördelar.
Vi skapar den första parametern av typen Choice Parameter och den andra — Active Choices Reactive Reference Parameter. I parametern av typen Choice lägger vi manuellt till namnen på repositoryn där vår mikrotjänsters kod förvaras i Choices-fältet.

Om denna artikel tilltalar publiken kommer jag i nästa artikel att beskriva processen för att konfigurera uppgifter i Jenkins, med hjälp av beskrivning genom kod (Configuration as Code), vilket innebär att vi inte behöver ange namn på lagren manuellt och skapa parametrar; allt kommer att ske automatiskt (vår kod kommer att få en lista med lagren från SCM och skapa en parameter med denna lista).

Värdena för den andra parametern kommer att fyllas dynamiskt, beroende på vilket värde den första parametern antar (test1 eller test2), då varje lager har sin egen lista med commits.

Aktiva Val Reaktiv Referensparameter har följande fält att fylla i:

1. Namn – namn på parametern.
2. Script – koden som kommer att köras varje gång värdet av parametern i fältet Referenced parameter ändras (i vårt fall, när vi väljer mellan test1 och test2).
3. Beskrivning – en kort beskrivning av parametern.
4. Valtyp – typ av objekt som kommer att returneras av skriptet (i vårt fall kommer vi att returnera html-kod).
5. Refererad parameter – namnet på parametern vars värdeändring kommer att köra koden från sektionen Script.

Låt oss gå vidare till att fylla i det mest grundläggande fältet i denna parameter. Vi har två alternativ att välja mellan: användning av Groovy-skript eller Scriptler-skript.
Vi väljer det första, eftersom Scriptler bara är ett plugin som sparar de skript du tidigare har skrivit och låter dig använda dem i andra uppgifter utan att behöva kopiera och klistra in igen.

Groovy-kod för att hämta alla commits från det valda lagret:

AUTH = "användarnamn och lösenord i Base64"                           
GIT_URL = "url till din SCM (https://bitbucket.org/)"                       
PROJECT_NAME = "namnet på projektområdet där repository finns"

def htmlBuild() {
    html = """
            <html>
            <head>
            <meta charset="windows-1251">
            <style type="text/css">
            div.grayTable {
            text-align: left;
            border-collapse: collapse;
            }
            .divTable.grayTable .divTableCell, .divTable.grayTable .divTableHead {
            padding: 0px 3px;
            }
            .divTable.grayTable .divTableBody .divTableCell {
            font-size: 13px;
            }
            </style>
            </head>
            <body>
        """

    def commitOptions = ""
    getCommitsForMicroservice(MICROSERVICE_NAME).each {
        commitOptions += "<option style='font-style: italic' value='COMMIT=${it.getKey()}'>${it}</option>"
    }
    html += """<p style="display: inline-block;">
        <select id="commit_id" size="1" name="value">
            ${commitOptions}
        </select></p></div>"""

    html += """
            </div>
            </div>
            </div>
            </body>
            </html>
         """
    return html
}

def getCommitsForMicroservice(microserviceRepo) {
    def commits = [:]
    def endpoint = GIT_URL + "\/rest\/api\/1.0\/projects\/${PROJECT_NAME}\/repos\/${microserviceRepo}\/commits"
    def conn = new URL(endpoint).openConnection()
    conn.setRequestProperty("Authorization", "Basic ${AUTH}")
    def response = new groovy.json.JsonSlurper().parseText(conn.content.text)
    response.values.each {
        commits.put(it.displayId, it.message)
    }
    return commits
}

return htmlBuild()

Om man inte går in på detaljer får denna kod namnet på mikrotjänsten (MICROSERVICE_NAME) som indata, skickar en begäran till Bitbucket (metod getCommitsForMicroservice), använder dess API och hämtar id och commit message för alla commits för denna mikrotjänst.
Som nämnts tidigare ska denna kod returnera html som kommer att visas på sidan Bygg med parametrar i Jenkins, så vi omsluter alla erhållna värden från Bitbucket i en lista och lägger till dem i select.

Efter att ha utfört alla dessa steg bör vi få en sådan vacker sida. Bygg med parametrar.

Om vi valde mikrotjänsten test1:

Om vi valde mikrotjänsten test2:

Håller ni med om att det kommer att vara mycket mer bekvämt för användaren att interagera med er uppgift på detta sätt, istället för att behöva kopiera url och leta efter rätt commit id varje gång.

P.S. I denna artikel ges ett mycket förenklat exempel som kanske inte har praktisk tillämpning i detta format, eftersom byggnader har betydligt fler olika parametrar, men syftet med denna artikel var att visa hur verktyget fungerar, snarare än att ge en fungerande lösning.

P.S.S. Som jag tidigare nämnt, om denna artikel är användbar, så kommer nästa att handla om dynamisk konfiguration av Jenkins-uppgifter via kod.

Källa: habr.com