🥇Създаване на динамични параметри в задача на Jenkins или как да направите задачата си лесна за използване

Добър ден, Хабр!

Днес бих искал да споделя един от начините за използване Плъгин за активен избор изпълнете задачата Дженкинс най-унифицирани и разбираеми за потребителя.

въведение

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

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

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

Задача

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

Входни данни

Имаме няколко хранилища, които съдържат изходния код на различни микроуслуги.

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

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

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

КАКВОТО Е

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

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

КАКТО ДА БЪДЕ

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

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

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

Активен избор Реактивен референтен параметър има следните полета за попълване:

Име – име на параметър.
Сценарий - код, който ще се изпълнява при всяка промяна на стойността на параметъра от полето Referenced parameter (в нашия случай, когато избираме между test1 и test2).
Описание – кратко описание на параметъра.
Тип избор - вида на обекта, върнат от скрипта (в нашия случай ще върнем html кода).
референтен параметър – името на параметъра, при промяна на стойността на който ще се изпълнява кодът от секцията Скрипт.

Нека да продължим директно към попълването на най-важното поле в този параметър. Предлагат ни се два вида изпълнение, от които да избираме: използване Groovy скрипт или Scriptler скрипт.
Ние избираме първия, тъй като 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 и получава идентификатора и съобщението за ангажиране на всички ангажименти за дадената микроуслуга.
Както споменахме по-рано, този код трябва да върне html, който ще бъде показан на страницата Изграждане с параметри в Jenkins, така че обвиваме всички получени стойности от Bitbucket в списък и ги добавяме към избраното.

След като изпълним всички стъпки, трябва да получим такава красива страница Изграждане с параметри.

Ако сте избрали микроуслугата test1:

Ако сте избрали микроуслугата test2:

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

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

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

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

Създаване на динамични параметри в задача на Jenkins или как да направите задачата си лесна за използване