Dry Goods | JENKINS2.0 Pipeline Framework (IPipeline)--A practical approach to optimization (II.)

Click on the "ZTE developer community" above to focus on our

Read a first-line developer's original article every day.

Problem description

Jenkins2.0 Pipeline Frame IPipeline (that is, PLLL Library) set the trigger conditions for Mergeci to change merged mode and fixed, that is, the code to go after +2 points, Then the core member clicks the submit button to push the code into the library before triggering the MERGECI process, the VERIFYCI and mergeci process of the process as shown in the following illustration:

In combination with the above figure we can find that there is a problem here is once the code goes through (+2 points), and then the core member through (SUBMIT), the code immediately into the warehouse, and then trigger the MERGECI process, if the Mergeci run error, That error has been stored at this time and has affected subsequent developers to fit into the code.

In combination with the actual characteristics of the development of the project agreement, it is likely that the VERIFYCI after the Mergeci will interact with others, which may lead to errors in the Trunk Branch code, the development of the interaction between developers, and ultimately affect the efficiency of code submission integration.

Based on this situation, we propose a pattern is that mergeci by the code inspector in the Gerrit on the +2 points to trigger, only to Mergeci run through, the code will be pushed into the storage, this way brings a most direct benefit is the backbone branch of the code is always correct, And not because of mergeci error to affect others code, and the method brings another advantage is not to set a key role to be responsible for the submit code warehousing, only need code to go to check personnel can, this also increased the degree of automation, save manpower. The process can be motioned to the following diagram:

Therefore, this mergeci of the PLLL library does not meet this project, so we decided to extend the PLLL library support for the Mergeci run mode. Optimization Practice

By overloading the property settings function of the Plll library, you have added settings that perform different trigger conditions according to the CI type mergeci:

/**

* Tool Name: set_default_properties

* Tool Description: Set default parameters

* Parameter Description:

*-CITYPE:CI type

*-args: Parameter list

**/

def set_default_properties (Citype, args) {

def buildparameters = []

def buildtriggers = []

Set_parameters_properties (buildparameters, args)

Set_cron_properties (buildtriggers, args)

Set_gerrit_properties (Citype, Buildparameters, buildtriggers, args)

/*--------parameter-------* *

Properties ([

[$class: ' Gitlabconnectionproperty ', gitlabconnection: '],

[$class: ' Rebuildsettings ', Autorebuild:false, Rebuilddisabled:false],

Builddiscarder (artifactdaystokeepstr: ', Artifactnumtokeepstr: ', daystokeepstr: ' Logrotator ', numToKeepStr: ' 100 ')),

Parameters (Buildparameters),

Pipelinetriggers (Buildtriggers)

])

/* Empty Temporary variable *

Buildparameters=null

Buildtriggers=null

Return

}

/**

* Function Name: Set Gerrit Property

**/

def set_gerrit_properties (Citype, Buildparameters, buildtriggers, args)

{

// ... Here the code omitted ...

if ("verifyci" = = "${citype}") {

Gerritevents = [

Patchsetcreated (

Excludedrafts:false,

Excludenocodechange:true,

Excludetrivialrebase:false

),

Draftpublished ()

]

If the CI type is MERGECI, the set trigger condition is Code-review +2 to trigger

}else if ("Mergeci" = "${citype}") {

Gerritevents = [

commentadded (commentaddedtriggerapprovalvalue: ' +2 ', verdictcategory: ' Code-review ')

]

}

// ... Here the code omitted ...

}

It is known from the Code, in the Set_gerrit_properties function, made a special judgment, if mergeci, the trigger condition is set to Code-review +2 alone, so that you can meet the requirements

Use examples:

If you explicitly specify the Mergeci type when you invoke Plll.set_default_properties to set the project properties in the Jenkinsfile of Mergeci, for example, set the default property parameter in the Jenkinsfile code of this project:

Def set_default_properties () {

Plll.set_default_properties ("Mergeci", [

/* Associated Gerrit * *

gerrit:[

Server: "${env." Gerrit_server_name} ",

Projects:[[project: "${env." Gerrit_project} ", Branch:" ${plll.getjobbasename ()} "]]

],

/* Custom Parameters * *

parameters:[

Choice (choices: ' Yes\nno ', Description: ' Empty compilation Environment ', Name: ' Clean_all '),

String (defaultvalue: "${plll.getjobbasename ()}", Description: ' Trigger branch ', Name: ' Branch_tag ')

],

]);

}

In addition, you need to make the configuration as shown in the Mergeci Gerrit trigger settings in Jenkins System management:

Analysis of advantages and disadvantages 1. Advantages:

Developers are independent of others, the wrong code can not be stored in the library, does not affect others

Trunk Branch code is always correct and does not affect others pull code validation and normal code

No team core members are required to submit operations, and once the Mergeci is properly run, the code is automatically stored

2. Disadvantages:

The principle determines that it cannot be parallel, so it needs to be considered as appropriate according to the different project conditions. However, from the actual practice of this project, the project Verifyci support several tasks concurrent execution, and Mergeci queued execution, but because Mergeci execution faster, and conflict is very few, so Mergeci code can be smoothly together, happiness than before there is a great improvement Promotion Suggestions

The relevant optimization improvement points in this article can be extended to MERGECI projects where the developer code could not be combined due to frequent conflicting errors.

Expand your Reading

Dry Goods | JENKINS2.0 Pipeline Framework (IPipeline) Optimization of Practical road (a) Dry goods | JENKINS2.0 Pipeline Framework (IPipeline)--A practical approach to optimization (II.)