Two ways to call the api of jenkins

Jenkins DroidTestbed

In this system, Jenkins is responsible for regularly detecting code Code Repositoryupdates in the code base ( ). When new code submissions are detected, the latest code is automatically used for construction, and the built package (apk) is used to trigger the automated test platform ( DroidTestbed) to execute the test task.

Then let's talk about the branch management module.

Since our continuous integration platform usually monitors more than one product, and each product monitors more than one tag (such as /trunk, /projects/cn/10.9.8), our continuous integration platform needs to have the function of branch management, That is, for each tag of each product, a branch is created separately, and the test case collection test equipment is separately specified for each branch.

In terms of specific implementation, based on the principle of single responsibility, we have divided the functions as follows:

Create a Job for each branch on the Jenkins side;
Configure test resources on the DroidTestbedend, bind test case sets and test equipment for each branch, and each branch will have a separate branch_id;
In the Job configuration on the Jenkins side, save the DroidTestbedcorresponding branch in branch_id, and realize Jenkinsthe DroidTestbedassociation with .

The whole process does not seem to be a problem, so why do you need to modify the branch management module?

The problem is with the branch configuration.

Imagine that every time a branch is added or modified, since the configurations of Jenkins and DroidTestbed are independent, we can only configure them separately on the two platforms.

On the other hand, the configuration itself is more complicated. For example, the parameters that need to be set on the Jenkins side include: repository_url, tag, ref_tag, ref_revision, branch_id, schedule, user_name, etc. Most of these parameters are also in DroidTestbed end to configure.

Historically, when it comes to complex and repetitive manual operations, it is prone to error. This is indeed the case. After this function goes online, due to the complicated configuration, every time students in the business group want to add a monitoring branch, they need to find an administrator to help with the configuration (to be honest, the administrator is not confident that the business classmates can configure it correctly); even if It is an administrator, and there have been several misconfigurations due to negligence.

So, how to solve this problem?

Introduction to the Jenkins Remote API

After going around such a big circle, I finally led to the topic of this article, Jenkins Remote API.

In fact, Jenkins itself supports rich API interfaces, and we can basically implement all the required functions by calling the interfaces remotely, such as:

Get Job Status Information from Jenkins
Trigger Jenkins to execute the build
Create, copy, modify, delete jobs

Going back to the previous case, we can put all the configuration operations in , and only need to automatically call the Remote API of Jenkins DroidTestbedwhen saving the configuration items to synchronize the configuration.DroidTestbed

Jenkins Remote API call

Now let's see how to call Jenkins' Remote API.

The Remote API of Jenkins is REST-likeprovided in the form of , and the operation of Jenkins can be realized by performing a POST request to a specific API.

For example, the Jenkins site we built is http://jenkins.debugtalk.com:8080, then, we http://jenkins.debugtalk.com:8080/apican view all available APIs on the site; if we want to operate a specific job, such as the job name android_core_dashboard_trunk, its management page is http://jenkins.debugtalk.com:8080/job/android_core_dashboard_trunk, then we http://jenkins.debugtalk.com:8080/job/android_core_dashboard_trunk/api/can view it by visiting to the APIs available for this job.

For a more detailed introduction to the POST call method, please refer to the official wiki of Jenkins, so I won't introduce it too much here.

It can be seen that it is more primitive to perform a POST request operation to a specific API, because we need to pay attention to too many low-level details. In fact, some seniors have already encapsulated the details of the underlying POST operation in response to this pain point, forming some wrappermore convenient operations from the upper layer.

The functions of this type wrapperof implementation are similar, and it is convenient for us to call the Jenkins API in the code in a more concise way to realize the remote management of Jenkins. We only need to choose the corresponding programming language according to the specific programming language we use wrapper. Of course, if we don't find a suitable one, we can also refer to the existing open source wrapperand build a new wheel ourselves, the principle is the same.

In the official wiki of Jenkins, two more mature ones are recommended API wrapper, one based on Python salimfadhley/jenkinsapiand the other based on Ruby arangamani/jenkins_api_client.

For salimfadhley/jenkinsapiexample, by using jenkinsapi, we can easily manage Jenkins in Python. Examples of common operations are as follows.

52

 
     >>>  
     import
      jenkinsapi 
    
     >>>  
     from
      jenkinsapi.jenkins 
     import
      Jenkins 
    
     # Specify the Jenkins instance 
    
     >>> 
     J = Jenkins( 
     'http://jenkins.debugtalk.com:8080'
     ) 
    
     # View Jenkins version 
    
     >>> 
     J.version 
    
     1.542 
    
     # View all jobs in Jenkins 
    
     >>> 
     J.keys() 
    
      [ 
     'foo'
     , 
     'test_jenkinsapi'
     ] 
    
     # View the configuration information of the specified job 
    
     >>> 
     J[ 
     'test_jenkinsapi'
     ].get_config() 
    
     # Create Jenkins job 
    
     >>> 
     jobName = 
     'test_job' 
    
     >>> 
     EMPTY_JOB_CONFIG = 
     ''' 
    
      <?xml version='1.0' encoding='UTF-8'?> 
    
      <project> 
    
      <actions>jkkjjk</actions> 
    
      <description></description> 
    
      <keepDependencies>false</keepDependencies> 
    
      <properties/> 
    
      <scm class="hudson.scm.NullSCM"/> 
    
      <canRoam>true</canRoam> 
    
      <disabled>false</disabled> 
    
      <blockBuildWhenDownstreamBuilding>false</blockBuildWhenDownstreamBuilding> 
    
      <blockBuildWhenUpstreamBuilding>false</blockBuildWhenUpstreamBuilding> 
    
      <triggers class="vector"/> 
    
      <concurrentBuild>false</concurrentBuild> 
    
      <builders/> 
    
      <publishers/> 
    
      <buildWrappers/> 
    
      </project> 
    
      ''' 
    
     >>> 
     new_job = J.create_job(jobName, EMPTY_JOB_CONFIG) 
    
     # Update the configuration of the Jenkins job 
    
     >>>  
     import
      xml.etree.ElementTree 
     as
      et 
    
     >>> 
     new_conf = new_job.get_config() 
    
     >>> root = et.fromstring(new_conf.strip()) 
    
     >>> builders = root.find( 
     'builders') 
    
     >>> shell = et.SubElement(builders, 
     'hudson.tasks.Shell') 
    
     >>> command = et.SubElement(shell, 
     'command') 
    
     >>> command.text = 
     "ls" 
    
     >>> J[jobName].update_config(et.tostring(root)) 
    
     # 删除Jenkins job 
    
     >>> J.delete_job(jobName)

更多的使用方法可参考项目文档。

有些同学在认真研究了这些开源库后也许会说，官方文档已经翻遍了，但是文档中对用法的描述太少了，也没给出API调用的示例，还是不知道怎么使用啊。这个问题在开源库中的确也是普遍存在的。

To introduce a technique, usually excellent open source libraries attach great importance to testing. The author may not explain the calling method of each API interface in the document, but usually write more complete test code for each interface. By reading the test code, we can fully understand the usage of the API interface, which is much more efficient than reading the documentation directly.