Good day, Habr!
Today I would like to share one of the ways to use to make the task in Jenkins the most standardized and understandable for the user.
Introduction
The abbreviation DevOps is no longer something new for the IT community. For many people, the phrase 'to achieve DevOps' is associated with a magical button that, when pressed, automatically turns application code into a deployed and tested application (it's actually more complex, but we will abstract from all processes).
So, we received a request to create such a magical button so that administrators could deploy the application with a single click. There are various ways to implement this task: from writing a bot for one of the messengers to developing a separate application. Nevertheless, the goal remains the same – to make the build and deployment of the application as transparent and convenient as possible.
In our case, we will use Jenkins.
Task
Create a user-friendly Jenkins job that will trigger the build and/or deployment of the selected microservice in a specific version.
Input data
We have several repositories containing the source code of various microservices.
Defining parameters
The following parameters must be input to our job:
- The repository URL with the code for the microservice that we want to build and deploy when the job is triggered.
- The commit ID from which the build will be made.
AS IS
The simplest way to accomplish the task is to create two parameters of type String.
In this case, the user will need to manually input the path to the repository and the commit ID, which, as you agree, is not very convenient.
AS TO BE
Now let's try a different type of parameter to explore all its advantages.
We will create the first parameter as a Choice Parameter and the second as an Active Choices Reactive Reference Parameter. In the Choice type parameter, we will manually add the names of the repositories where our microservices' code is stored in the Choices field.
If this article is well-received by the audience, I will describe the process of configuring tasks in Jenkins in the next article, using the configuration as code description, meaning we won't need to manually enter repository names or create parameters; everything will happen automatically (our code will get the list of repositories from SCM and create a parameter with that list).
The values of the second parameter will be populated dynamically, depending on what value the first parameter takes (test1 or test2), as each repository has its own list of commits.
Active Choices Reactive Reference Parameter has the following fields to fill out:
- Name – parameter name.
- Script – the code that will be executed every time the value of the Referenced parameter is changed (in our case, when selecting between test1 and test2).
- Description – a brief description of the parameter.
- Choice Type – the type of object returned by the script (in our case, we will return HTML code).
- Referenced parameter – the name of the parameter, the value of which, when changed, will trigger the code in the Script section.
Let's move directly to filling in the most important field in this parameter. We are offered two types of implementations: Groovy Script or Scriptler Script.
We choose the first one, as Scriptler is just a plugin that saves scripts you have previously written and allows you to use them in other tasks without repeating copy-paste.
Groovy code to fetch all commits from the selected repository:
AUTH = "login and password in Base64"
GIT_URL = "url to your SCM (https://bitbucket.org/)"
PROJECT_NAME = "name of the project space where the repositories are located"
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()Without going into details, this code takes the name of the microservice (MICROSERVICE_NAME), sends a request to Bitbucket (method getCommitsForMicroservice), using its API, and retrieves the id and commit message of all commits for this microservice.
As mentioned earlier, this code should return HTML that will be displayed on the Build with Parameters page in Jenkins, so all the values received from Bitbucket are wrapped in a list and added to the select.
After completing all actions, we should get a nice page like this: Build with Parameters.
If we selected the microservice test1:
If we selected the microservice test2:
You will agree that it will be much more convenient for the user to interact with your task this way than to copy the URL and search for the required commit id every time.
P.S. This article provides a very simplified example that may not have practical application in its current form, as configurations have many more varying parameters. However, the goal of this article was to demonstrate the tool's functionality rather than provide a working solution.
P.S.S. As mentioned earlier, if this article proves useful, the next one will cover dynamic configuration of Jenkins tasks via code..
Source: habr.com
