Създаване на динамични параметри в Jenkins job, или как да направите задачата си удобна за потребителя

Добър вечер, Хабр!

Днес бих искал да споделя един от начините, по които с помощта на Active Choices Plugin можем да изпълним задача в Jenkins най-унифициран и разбираем за потребителите начин.

Въведение

Такава абревиатура като DevOps отдавна не е нещо ново за ИТ общността. За много хора фразата «извършване на DevOps» е свързана с някакъв магически бутон, при натискането на който кодът на приложението автоматично се преобразува в разпределено и тествано приложение (всичко наистина е по-сложно, но абстрахираме от всички процеси).

И така, получихме поръчка да създадем такъв магически бутон, за да може администраторите да разполагат приложението с едно щракване. Има различни начини за реализиране на тази задача: от написването на бот за някой от мессенджърите до разработването на отделно приложение. Въпреки това целта на всичко това е една – да направим стартирането на изграждането и разполагането на приложението най-прозрачно и удобно.

В нашия случай ще използваме Jenkins.

Задача

Създаване на удобна Jenkins работа, която ще стартира изграждането и (или) разполагането на избрания микросервис с определена версия.

Входни данни

Разполагаме с няколко репозитория, в които се съхранява изходният код на различни микросервиси.

Определяне на параметрите

В нашата работа трябва да постъпват следните параметри:

1. URL на репозитория с кода на микросервиса, който искаме да изградим и разположим при стартиране на работата.
2. ID на комита, от който ще се извършва изграждането.

AS IS

Най-простият начин за изпълнение на поставената задача е да създадем два параметъра с тип String.

В този случай потребителят ще трябва ръчно да въведе пътя до репозитория и id на комита, което, признайте, не е особено удобно.

AS TO BE

А сега да опитаме друг тип параметри, за да разгледаме всички негови предимства.
Нека създадем първи параметър с тип Choice Parameter, втори — Active Choices Reactive Reference Parameter. В параметъра с тип Choice добавяме ръчно в полето Choices имената на репозиторите, където се съхранява кодът на нашите микросервиси.

Ако тази статия хареса на аудиторията, в следващата статия ще опиша процеса на конфигуриране на задачи в Jenkins, използвайки описание през код (Configuration as code), т.е. няма да трябва ръчно да въвеждаме имената на репозиториите и да създаваме параметри, всичко ще се случи автоматично (нашият код ще получи списък на репозиториите от SCM и ще създаде параметър с този списък).

Стойностите на втория параметър ще се запълват динамично, в зависимост от това каква стойност ще приеме първият параметър (test1 или test2), тъй като всеки репозиторий има свой собствен списък с комити.

Active Choices Reactive Reference Parameter има следните полета за попълване:

1. Name – име на параметъра.
2. Script – кодът, който ще се изпълнява всеки път, когато стойността на параметъра от полето Referenced parameter бъде променена (в нашия случай, когато избираме между test1 и test2).
3. Описание – кратко описание на параметъра.
4. Choice Type – типът на обекта, върнат от скрипта (в нашия случай ще връщаме html код).
5. Referenced parameter – името на параметъра, при промяна на стойността на който ще се изпълнява кодът от секцията Script.

Преминаваме директно към попълването на най-важното поле в този параметър. На разположение имаме два вида реализации: използване на Groovy Script или Scriptler Script.
Избираме първото, тъй като Scriptler е просто плъгин, който съхранява вече написаните от вас скриптове и позволява да ги използвате в други задачи без повторно копиране и поставяне.

Groovy код за получаване на всички комити от избрания репозиторий:

AUTH = "логин и парола в Base64"                           
GIT_URL = "url до вашата SCM (https://bitbucket.org/)"                       
PROJECT_NAME = "име на проектната област, където се намират репозиториите"

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

Ако не навлизаме в детайли, този код приема името на микросервиса (MICROSERVICE_NAME), изпраща заявка до Bitbucket (метод getCommitsForMicroservice), използвайки неговото API, и получава id и commit message на всички комити за този микросервис.
Както вече споменахме, този код трябва да връща html, който ще се покаже на страницата Build with Parameters в Jenkins, затова всички получени стойности от Bitbucket обвиваме в списък и добавяме в select.

След извършване на всичките действия, трябва да получим такава красива страничка Build with Parameters.

Ако сме избрали микросервис test1:

Ако сме избрали микросервис test2:

Съгласете се, че на потребителя ще му бъде много по-удобно да взаимодейства с вашата задача по този начин, отколкото всеки път да копира url и да търси нужния commit id.

P.S. В тази статия е представен много опростен пример, който вероятно няма практическо приложение в този вид, тъй като сборките имат многократно повече различни параметри, но целта на тази статия беше да демонстрира работата на инструмента, а не да предостави работно решение.

P.S.S. Както вече споменах по-рано, ако тази статия е полезна, следващата ще бъде за динамично конфигуриране на задачи в Jenkins чрез код.

Източник: habr.com