Jenkins解决编译时多补丁依赖关系的问题

背景：
　　Jenkins是一个基于java的持续集成工具，可以用于git-gerrit-jenkins绑定起来实现自动构建系统，用于对上传的代码进行自动构建代码测试检查。　　

　　每次从本地coding完成后，push一份patch至gerrit，就会触发jenkins的自动构建，对这份patch做一些codestytle，codestatic，codebuild等的测试检查。codebuild的原理是将这一份patch下载到服务器上的sdk环境中，然后进行编译。根据编译的log信息可以确定本次编译的成功与否。此时，问题来了，像上述所说的每上传一次patch，就会把这个patch拉到服务器上的sdk中，也就是说，只会下载一个patch。那么，当两个甚至多个patch之间存在依赖关系的时候（A依赖于B、AB互相依赖），只下载一个patch很明显就会导致编译不成功。

　　本文就是将会讲述如何解决这种问题。

　　多补丁依赖关系问题分成两种情况，第一种是同一个仓库下多补丁依赖的问题，第二种是不同仓库多补丁依赖的问题。首先讲的是前者。

一、同仓库多补丁依赖问题

　　Gerrit给咱们提供了多种下载补丁的方式，分别是：cherry-pick、format patch、pull、checkout。不同方式之间下载的的效果不一样。

1.  cherry-pick方式，详细命令为：

   git fetch ssh://user@Gerrit.com:xxxxx/project refs/xx/change_number/patch_set && git cherry-pick FETCH_HEAD

   下载补丁的效果是，将补丁拉取到本地，修改内容的同时也会把本次的commit合并到本地的当前分支，并且存在于当前分支commit信息的HEAD。但是通过cherry-pick命令有且只能下载一份patch，因此cherry-pick不能解决多补丁依赖的问题； 
2. format patch方式，详细命令为：

   git fetch ssh://user@Gerrit.com:xxxxx/project refs/xx/change_number/patch_set && git format-patch -1 --stdout FETCH_HEAD

   这里是将patch以补丁的形式合并到本地SDK中，并不会合并到当前分支的commit信息中。

3. pull方式
4. checkout方式

5. git fetch ssh://user@Gerrit.com:xxxxx/project refs/xx/change_number/patch_set && git 

   这

二、不同仓库多补丁依赖的问题

...持续更新中。

Jenkins解决编译时多补丁依赖关系的问题

原文：https://www.cnblogs.com/jeffreyo/p/13255820.html