Dynamische parameters maken in een Jenkins-job, of hoe je jouw taak gebruiksvriendelijk maakt.

Goedemiddag, Habr!

Vandaag wil ik een van de manieren delen om met behulp van Active Choices Plugin de taak in Jenkins de meest uniforme en begrijpelijke manier voor de gebruiker te maken.

Inleiding

De afkorting DevOps is al een lange tijd geen onbekende meer voor de IT-gemeenschap. Voor veel mensen wordt de zin "DevOps uitvoeren" geassocieerd met een magische knop, waarop, wanneer deze wordt ingedrukt, de code van de applicatie automatisch verandert in een uitgerolde en geteste applicatie (in werkelijkheid is alles ingewikkelder, maar we abstraheren van alle processen).

Dus, we hebben een opdracht gekregen om zo'n magische knop te maken, zodat beheerders de applicatie met één klik kunnen uitrollen. Er zijn verschillende manieren om deze taak uit te voeren: van het schrijven van een bot voor een van de messengers tot het ontwikkelen van een afzonderlijke applicatie. Desondanks is het doel van dit alles hetzelfde - de lancering van de build en het uitrollen van de applicatie zo transparant en gebruiksvriendelijk mogelijk te maken.

In ons geval gaan we Jenkins.

Task

een gebruiksvriendelijke Jenkins-job maken, die de build en (of) deployment van de geselecteerde microservice van een bepaalde versie zal starten.

Invoergegevens

We hebben verschillende repositories waar de broncode van verschillende microservices is opgeslagen.

Parameters definiëren

De volgende parameters moeten binnenkomen bij onze job:

1. URL van de repository met de code van de microservice die we willen bouwen en uitrollen bij het starten van de job.
2. Commit-ID waaruit de build zal plaatsvinden.

AS IS

De eenvoudigste manier om de gestelde taak uit te voeren, is door twee parameters van het type String te maken.

In dit geval moet de gebruiker handmatig het pad naar de repository en het commit-ID invoeren, wat, laten we eerlijk zijn, niet erg praktisch is.

AS TO BE

Laten we nu een ander type parameters proberen om alle voordelen ervan te bekijken.
We maken de eerste parameter met het type Choice Parameter, en de tweede — Active Choices Reactive Reference Parameter. Voeg handmatig in het veld Choices namen van de repositories toe waar de code van onze microservices is opgeslagen.

Als dit artikel de lezers bevalt, zal ik in het volgende artikel het proces van het configureren van taken in Jenkins beschrijven, gebruikmakend van de beschrijving via code (Configuration as code), wat betekent dat we geen namen van repositories handmatig hoeven in te voeren en parameters hoeven te creëren; alles gebeurt automatisch (onze code zal de lijst van repositories uit SCM ophalen en een parameter met deze lijst creëren).

De waarden van de tweede parameter zullen dynamisch worden ingevuld, afhankelijk van welke waarde de eerste parameter aanneemt (test1 of test2), aangezien elke repository zijn eigen lijst met commits heeft.

Active Choices Reactive Reference Parameter heeft de volgende velden om in te vullen:

1. Naam – naam van de parameter.
2. Script – de code die elke keer wordt uitgevoerd wanneer de waarde van de parameter uit het Referenced parameter-veld verandert (in ons geval, wanneer we kiezen tussen test1 en test2).
3. Beschrijving – een korte beschrijving van de parameter.
4. Choice Type – het type object dat door het script wordt teruggegeven (in ons geval gaan we html-code teruggeven).
5. Referenced parameter – de naam van de parameter waarvan de waarde verandert, waardoor de code in de sectie Script wordt uitgevoerd.

Laten we direct overgaan tot het invullen van het belangrijkste veld in deze parameter. We hebben de keuze uit twee soorten implementaties: gebruik Groovy Script of Scriptler Script.
We kiezen de eerste, aangezien Scriptler slechts een plugin is die eerder door jou geschreven scripts opslaat en deze in andere taken zonder herhaaldelijke copy-paste mogelijk maakt.

Groovy-code om alle commits uit de geselecteerde repository op te halen:

AUTH = "login en wachtwoord in Base64"                           
GIT_URL = "url naar uw SCM (https://bitbucket.org/)"                       
PROJECT_NAME = "naam van het projectgebied waar de repositories zich bevinden"

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()

Als we niet op de details ingaan, dan haalt deze code de naam van de microservice (MICROSERVICE_NAME) binnen, stuurt een verzoek naar Bitbucket (methode getCommitsForMicroservice), gebruikmakend van zijn API, en krijgt de id en commit message van alle commits voor deze microservice.
Zoals eerder vermeld, moet deze code html retourneren, die op de pagina Build with Parameters in Jenkins wordt weergegeven, daarom wikkelen we alle waarden die we uit Bitbucket hebben verkregen in een lijst en voegen deze toe aan select.

Na het uitvoeren van alle handelingen zouden we een mooie pagina moeten krijgen Build with Parameters.

Als we microservice test1 hebben gekozen:

Als we microservice test2 hebben gekozen:

Geeft u toe dat het voor de gebruiker veel handiger zal zijn om op deze manier met uw taak te interageren dan elke keer de url te kopiëren en naar de juiste commit id te zoeken.

P.S. In dit artikel wordt een zeer vereenvoudigd voorbeeld gegeven, dat mogelijk niet praktisch toepasbaar is in deze vorm, aangezien builds veel meer verschillende parameters hebben. Het doel van dit artikel was echter om de werking van de tool te demonstreren, en niet om een werkende oplossing te bieden.

P.S.S. Zoals eerder vermeld, als dit artikel nuttig is, zal het volgende artikel over dynamische configuratie van Jenkins-taken via code.

Bron: habr.com