Introduction: This series of articles, around continuous integration: Jenkins+Docker+K8S related components, to achieve automatic management of source code compilation, packaging, image construction, deployment and other operations; This article describes Pipeline Pipeline usage.

First, Webhook principle

Pipeline Pipeline tasks are usually triggered automatically by configuring the address to be notified of source changes in a Git repository.

For example, in the Gitee warehouse, webhoo-based configuration can automatically call back the pre-set request address after pushing the code to the warehouse, thus triggering the packaging action after the code update. The basic process is as follows:

There are two core configurations involved:

  • Gitee callback: the notification address of a push request received by the warehouse; In the warehouse managementWebHooksIn the options;
  • Jenkins process: write assembly line tasks and deal with automatic process after code submission; Here, Jenkins’ address is required to be accessible from the Internet. There are many components on the Internet, so you can choose to build them by yourself.

Note: You can set the callback address at will first, copy the request parameters directly in the request log, and trigger Jenkins task in postman, which will be much more convenient in the test.

Combined with the help documents of Gitee, the parameter identifiers of different push actions are analyzed to determine the creation, push, deletion and other operations of branches, such as:

"after": "1c50471k92owjuh37dsadfs76ae06b79b6b66c57",
"before": "0000000000000000000000000000000000000000",
Copy the code

Create branches: before characters are 0; Delete branches: after characters are all 0;

Two, pipeline configuration

1. Plug-in installation

In Jenkins plugin management, install generic-Webhook-trigger plugin, pipeline related components have been installed at Jenkins initialization time.

2. Create an assembly line

Create a new Item, enter the task name, and select pipeline option:

Select the Webhook option and the page prompts how to trigger.

3. Trigger assembly line

http://user name: password @jenkins_url /generic-webhook-trigger/invokeCopy the code

If the authentication is passed in the preceding manner, pipeline execution is triggered and task logs are generated, indicating that the flow is smooth.

Three, Pipeline grammar

1. Structural grammar

  • Triggers: Triggering pipeline tasks based on hook mode;
  • Environment: Declare global common environment variables;
  • Stages: Defines task steps, that is, process stages;
  • Post. always: The action that is finally executed.

The overall structure of the general process is as follows:

pipeline {
    agent any
    triggers {}
    environment {}
    stages {}
    post { always {}}
}
Copy the code

Configuring the scripts under each node creates an automated pipeline task. Note that the Use Groovy sandbox option is not checked.

2. Parameter analysis

Parameter parsing here refers to that Gitee requests the parameters carried by Jenkins service through hook mechanism. Here it mainly parsed the POST parameters. See the explanation for the parsing method:

Here we select several parameters from the hook callback parameters used in the process. Here is how to parse them. Click Add in the figure above:

{
    "ref":"refs/heads/master"."repository": {"name":"butte-auto-parent"."git_http_url":"Warehouse address -URL"
    },
    "head_commit": {"committer": {"user_name":"Name of submitter",}},"before":"277bf91ba85996da6c"."after":"178d56ae06b79b6b66c"
}
Copy the code

The above parameters can be configured in sequence so that they can be used in the workflow.

3. Trigger node

This triggers module configuration. The core function is to load some parameters that trigger the process and use them later in the script. Other related configurations can be selected as required.

triggers { GenericTrigger( genericVariables: [ [key: 'ref', value: '$.ref'], [key: 'repository_name', value: '$.repository.name'], [key: 'repository_git_url', value: '$.repository.git_http_url'], [key: 'committer_name', value: '$.head_commit.committer.user_name'], [key: 'before', value: '$.before'], [key: 'after', value: '$. After']], / / causeString: 'Triggered on $ref', / / printContributedVariables: true, / / / / printPostContent print request parameters: true ) }Copy the code

4. Environment variables

Declare some global environment variables, or you can define them directly, and refer to them as ${variables} in the flow:

environment { branch = env.ref.split("/")[2].trim() is_master_branch = "master".equals(branch) is_create_branch = env.before.replace('0','').trim().equals("") is_delete_branch = env.after.replace('0','').trim().equals("") is_success =  false }Copy the code

Here, based on the hook request parameters, the branch action types are resolved: whether to create, delete, trunk branch, and define an indication of whether the IS_Success process was successful.

5. Segmented process

There are five steps: data parsing, branch pulling, Pom file processing, branch pushing, project packaging;

Stage ('Parse') {steps {echo "${branch} \n ${repository_name} \n ${repository_name} \n ${repository_git_URL} \n Repository_git_URL: ${committer_name}" script {if ("true". Equals (is_master_branch)) {echo" ${branch}"} if ("true". Equals (is_create_branch)) {echo" ${branch}"} if ("true". Equals (is_delete_branch)) {echo" ${branch}"}}}} // steps {script {if ("false". Equals (is_delete_branch)) {echo "steps: ${branch}" git branch: "${branch}",url: "${repository_git_url}"}}}} // stage('MvnPom') {steps {script {def Pom = readMavenPom file: 'pom.xml' def version = "${pom.version}" def encode = pom.getProperties().get("project.build.sourceEncoding") echo "Pom version: "+ version echo" "${branch}-"+version def devVersion = "${branch}-"+version+".jar" "+ devVersion echo" Put ("dev.version","${devVersion}".trim().toString()) // writeMavenPom file: 'pom.xml', model: Steps {script {echo "git push success"}}} step {script {echo "git push success"} Stage ('Package') {steps {script {sh 'MVN clean package-dmaven.test. skip=true' is_success =true}}}}Copy the code
  • Parses data: parses and outputs some parameter information;
  • Pull branch: combined with Git command, pull branch code;
  • Processing Pom files: reading and modifying Pom files;
  • Branch push: push branch code with Git command;
  • Project packaging: combined with Mvn command, complete the project packaging;

Note: when testing the process locally, there is no push code; After the project is packaged, the service is launched and published with shell script.

6. Message notification

At the end of the process, identify the execution identifier of the task is_success and notify relevant personnel whether the package is successful. The notification mode can be selected as email or other API notification type, but there are many descriptions:

post {
    always {
        script {
            echo "notify : ${committer_name} , pipeline is success : ${is_success}"
        }
    }
}
Copy the code

7. Execute logs

After completing the above pipeline pipeline script development, send requests continuously through postman tool to complete script debugging:

You can also click a different module in the flow to view the log information under this module:

Note: Complete pipeline script content at the end of the Gitee open source repository, there is a need to obtain their own.

Source code address

GitEE address https://gitee.com/cicadasmile/butte-auto-parent Wiki, https://gitee.com/cicadasmile/butte-java-noteCopy the code