Android 使用 Jenkins 参数化构建

2019年5月8日 141次阅读 来源: 为何是Hex的昵称

这几天，闲来无事，就想鼓捣鼓捣测试搭建的 Jenkins

Jenkins 上原有的 Android 相关的 Job 有编译 debug 的、编译 release 的和多渠道 release 的，一共三个 Job，感觉一点也不极客范，遂想折腾一下

关于 Tomcat ， Jenkins 等环境，编译工具链的安装这里就不介绍了，网上一大堆，都玩烂了，也没什么难度，下面进入正题

首先，想要把三个 Job 集合起来，肯定要用到参数化构建的，下面是我需要的参数

参数名作用
Branch指定编译哪一个分支
BuildType编译类型 debug， release， 多渠道等
EmailList接收编译结果的邮箱列表

首先 Branch 参数，我一开始使用的是手动填写的方式，但是感觉不爽，后来在网上看到了 Dynamic Choice Parameter ，它可以使用脚本生成动态的下拉列表框

《Android 使用 Jenkins 参数化构建》 branch

代码如下

def git_address = "git@gitlab.xxxxx.com:xxxxx.git"
def Branches_build = ("git ls-remote -h " + git_address).execute()
Branches_build.text.readLines().collect {
    it.split()[1].replaceAll('refs/heads/', '')
}.unique()

这段代码的核心是 git ls-remote -h remote_address
ls-remote 的意思是：列出远程仓库中，所有可用的引用
-h / –heads 是用来只显示 refs/heads 的引用
命令运行效果如下

git ls-remote -h git@gitlab.xxxx.com:xxxx.git
e2e7cb5e614915627ec46188613aa0e68fff824d        refs/heads/dev
710ce06a02cca7e48e557dbc29d36d0791cb3c3a        refs/heads/master
18aacde7d9d7047d3e1581569fa901b2f8eb07ac        refs/heads/release/0.5.0_no_face_test
ae7ee8b75622dc69857462f7e5e9599f46afe90c        refs/heads/release/v0.2.0
1ed148ca137daca49663f760d72a72666cb7a761        refs/heads/release/v0.3.0
702c29dafdf5ac3fa9edb8ab2d4ee5803ae98553        refs/heads/release/v0.4.0
61d1466dd051e497722a03c2efbd77db9c853e3a        refs/heads/release/v0.5.0
6326873bdfc5819c3ca8ee756682d086d56614be        refs/heads/release/v0.5.3
6d2ea95393185f2d366a234aa0910d8e145d2bc2        refs/heads/release/v1.0.0
3f0ac34e9b334aae34030756c4a8c0470578ad0c        refs/heads/release/v1.0.1

it.split()[1].replaceAll(‘refs/heads/’, ”) 是把每一行分隔后，取第 1 个位置的字符串，然后把 refs/heads/ 替换为空字符串
最终效果如图

《Android 使用 Jenkins 参数化构建》 效果

第一个参数搞定，接下来是第二个 BuildType 这个就简单了，直接一个 Choice 即可搞定，第三个 EmailList 也很简单，一个 String Parameter，就不贴图了

在 配置 -> 源码管理 -> Branch Specifier (blank for ‘any’) 填入 ${Branch} 来指定分支

构建触发器 也不详细说了，我加上了 Poll SCM 每 15 分支检查一次，但是好像和参数化构建有冲突，上网搜这个，有人说，参数化构建和 Poll SCM 最好不要在一个 Job 里

构建环境 可以把 Set Build Name 勾上，这样就可以修改每个 Build 的名字了，在列表里看起来更直观，比如 #${BUILD_NUMBER}-${Branch}-${BuildType} ，就会在 Job 页显示形如 #25-dev-debug 的 Build Name，很直观

这里推荐一个插件 user build vars，它可以把开启构建的用户的相关信息写入到构建环境中
下面的表格是所有支持的参数

VariableDescription
BUILD_USERFull name (first name + last name)
BUILD_USER_FIRST_NAMEFirst name
BUILD_USER_LAST_NAMELast name
BUILD_USER_IDJenkins user ID
BUILD_USER_EMAILEmail address

安装后，在 构建环境 中，把 Set jenkins user build variables 勾上，就可以使用上面的参数了
这个插件很有用，比如自动发送编译结果的邮件给开启编译任务的人

然后是构建，我没有使用 Gradle 插件来编译，而是自己写的脚本

echo ${BUILD_NUMBER}
echo ${Branch}
echo ${BUILD_USER_EMAIL}
echo ${BUILD_USER}
source ~/.bash_profile

# 拷贝后的要用来存档的目录
output_app_dir="$WORKSPACE/app/build/jenkins"

# 编译工具输出的目录
output_apk_dir="$WORKSPACE/app/build/outputs"

build_type="${BuildType}"

# 上传蒲公英的 apk 路径
upload_apk_path=""

# 下面判断编译类型，来执行不同的 task
if [ "$build_type" == "debug" ]; then
  gradle clean assembleDebug --stacktrace
  mkdir "$output_app_dir"
  cp $output_apk_dir/apk/app-debug.apk $output_app_dir/debug_${BUILD_NUMBER}.apk
  upload_apk_path=$output_app_dir/debug_${BUILD_NUMBER}.apk
elif [ "$build_type" == "release" ]; then
  gradle clean assembleRelease --stacktrace
  mkdir "$output_app_dir"
  cp $output_apk_dir/apk/app-release.apk $output_app_dir/release_${BUILD_NUMBER}.apk
  cp $output_apk_dir/mapping/release/mapping.txt $output_app_dir/mapping_${BUILD_NUMBER}.txt
  upload_apk_path=$output_app_dir/release_${BUILD_NUMBER}.apk
else
  # 多渠道打包用的是 美团的 walle
  #gradle clean assembleReleaseChannels --stacktrace
  # -DBUGLY_ENABLED=true 是向 Gradle 中传递一个参数，用来开启 bugly 的 mapping 上传任务
  gradle clean -DBUGLY_ENABLED=true assembleReleaseChannels --stacktrace
  mkdir "$output_app_dir"
  cp -r $output_apk_dir/channels $output_app_dir/channels_${BUILD_NUMBER}
  cp $output_apk_dir/mapping/release/mapping.txt $output_app_dir/mapping_${BUILD_NUMBER}.txt
  # 找到含有指定渠道名的 apk 文件的路径用来上传蒲公英
  upload_apk_path=`find "$output_app_dir/channels_${BUILD_NUMBER}" -name "*-xxxx-*.apk"`
fi

#上传到蒲公英
echo "++++++++++++++upload to pgyer+++++++++++++"
#蒲公英上的User Key
uKey="xxxxxx"     
#蒲公英上的API Key
apiKey="xxxxx"    
#要上传的apk文件路径
APK_PATH="${upload_apk_path}"
#执行上传至蒲公英的命令
if [ -f "$APK_PATH" ]; then
  curl -F "file=@${APK_PATH}" -F "uKey=${uKey}" -F "_api_key=${apiKey}" http://www.pgyer.com/apiv1/app/upload
fi

BUGLY_ENABLED 的值是用来控制 bugly 开启和关闭状态的

bugly {
    appId = 'xxxxx' // 注册时分配的App ID
    appKey = 'xxxxxx' // 注册时分配的App Key
    // 获取 BUGLY_ENABLED 的值
    def isEnabled = System.getProperty("BUGLY_ENABLED", "false")
    System.out.println("BUGLY_ENABLED " + isEnabled)
    boolean enable = Boolean.parseBoolean(isEnabled)
    execute = enable
    upload = enable
    uploadMapping = enable
    uploadSymbol = enable
}

美团 walle 多渠道打包配置

walle {
    // 指定渠道包的输出路径
    apkOutputFolder = new File("${project.buildDir}/outputs/channels")
    // 尝试获取 Jenkins 的 BUILD_NUMBER 的值
    def buildNum = System.getenv("BUILD_NUMBER") as Integer ?: '${buildTime}'
    // 定制渠道包的APK的文件名称
    apkFileNameFormat = 'XXXXX-${channel}-${buildType}-v${versionName}-' + buildNum + '.apk'
    // 渠道配置文件
    channelFile = new File("${project.getProjectDir()}/channel")
}

构建后，用于存档的文件

app/build/jenkins/*.txt,app/build/jenkins/channels*/,app/build/jenkins/*.apk

最后是构建完成后的自动发送邮件，网上也有许多我这里不赘述了
我发送的是 ${BUILD_USER_EMAIL},${EmailList}

完！

    原文作者：为何是Hex的昵称
    原文地址: https://www.jianshu.com/p/ac6720878e58
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞