当 jenkins赶上Android Studio 3.0

概述

简介

jenkins是一个开源软件项目，是基于Java开发的一种持续集成工具，用于监控持续重复的工做，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能。
关于Android Studio持续集成的文章已是满天飞了，不过都是在AS 2.X的环境下面进行集成的，最近升级了AS 3.0以后，发现按照以前的一些方法没法在AS 3.0上顺利集成，原本很简单的几步操做，却调试了好久，下面简单记录一下调试的过程，可让一部分开发者少走弯路。

本文是基于GitLab集成，其他的相似于Git，SVN其实原理都同样，稍微有点区别，稍微调试一下就好。

正文

基本知识

简单的Groovy语法

普通标识符:以字母、美圆符号$或下划线_开始，不能以数字开始

def date = new Date()

引号标识符:使用单引号括住的字符串

def name = 'android'

括号{}：表示引用
美圆符号$：表示拼接

assemble${PRODUCT_FLAVOR}${BUILD_TYPE}
//至关于assembleWandoujiaRelease

基本的gradle命令

说来惭愧，平时都是点击AS的可视化按钮，不多去研究这些命令，直到此次debug，才发现，命令行在debug确实颇有用

• gradlew clean //删除app目录下的build文件
• gradlew build //编译debug跟release包
• gradlew assembleDebug //编译debug包
• gradlew assembleRelease //编译release包

jenkins提供的全局变量

这些变量能够在写脚本，包括gradle脚本以及python脚本的时候能够调用，咱们也能够本身经过插件来配置一些变量，用来进行构建不一样的渠道包，下面选取了一些经常使用的：

• BRANCH_NAME :项目分支名称
• CHANGE_AUTHOR:修改项目的做者
• BUILD_NUMBER:构建的序列号
• JOB_NAME:构建的项目名称
• WORKSPACE:服务器构建项目的位置
• JENKINS_HOME:jenkins的根目录
• GIT_COMMITTER_EMAIL: Git提交做者的邮箱

登录无效解决方案

当关掉jenkins的网页，再从新打开的时候，会让你从新登陆，可是当你输入正确的用户名跟密码的时候，却会提示你登录无效，解决方案以下:

• 1.找到安装目录下的config文件
• 2.找到useSecurity节点，将true改成false

<useSecurity>false</useSecurity>

• 三、找到authorizationStrategy跟securityRealm节点，删除这两个节点
• 四、重启jenkins，不知道怎么重启的，直接重启电脑，再次启动jenkins便可。

修改build.gradle文件

AS3.0升级了gradle，改动较大，对比一下以前的代码，即可以发现区别，主要是在flavor的添加时必须增长一个dimension，apk输出路径作了较大的修改，为了减小代码量，只贴出了变更的部分

android {
    signingConfigs {
        config {
            keyAlias 'demo'
            keyPassword '123456'
            storeFile file('chuangmei.jks')
            storePassword '123456'
            flavorDimensions "versionCode"
        }
    }
 
    flavorDimensions "market"
    productFlavors {
        xiaomi {
            dimension "market"
            manifestPlaceholders = [UMENG_CHANNEL_VALUE: "xiaomi"]
        }
        wandoujia {
            dimension "market"
            manifestPlaceholders = [UMENG_CHANNEL_VALUE: "wandoujia"]
        }
 
    }
    applicationVariants.all { variant ->
        variant.outputs.all { output ->
            outputFileName = variant.productFlavors[0].name + new Date().format('yyyyMMddHHmmss') + '-' + variant.buildType.name + '.apk'
        }
    }
}

安装jenkins

官网是jenkins.io，有三种安装方式，分别是war包，native包以及docker容器，这里我选择的是native包，由于这种方式能够帮助咱们安装一部分插件，基本上能够知足咱们的需求。

配置环境

插件安装

native包安装
基本够用，而后能够根据需求扩展
war包安装

• Git plugin
• Gradle Plugin
• SSH plugin
  这里选择的几个插件貌似可以打出apk，网上有不少文章，会安装不少插件，一来不必，二来不少插件已通过时了，最新的jenkins版本已经不支持，即便是经过本地上传的方式，除非使用较老的jenkins版本。

系统设置

设置构建路径
找到主目录，而后点击高级

修改构建路径

理解了groovy语法，上面的路径就很好理解了，这个是能够随便修改的

 

设置环境变量
找到全局属性，勾选环境变量，设置SDK路径

设置环境变量

 

全局工具配置

name能够随便填，对应的value则是相应的路径

JDK路径

JDK路径

Git路径

Git路径

Gradle路径

Gradle路径

 

配置项目

建立一个项目

名称随便填，这里选择自由风格的软件项目，选择第一个也能够，看本身需求

建立项目

 

配置项目

参数化构建

参数名称	参数类型	参数值
BUILD_TYPE	choice	Build，Debug
PRODUCT_FLAVOR	choice	Xiaomi,Wandoujia

参数化构建

构建环境

配置相应的构建环境

 

构建环境

构建

根据以前设置的条件进行编译操做

 

构建

构建后操做

主要是能够用来收集构建出来的apk以及相应的编译文件

 

构建后操做

开始构建

其实最花时间的仍是这里，由于，升级了AS 3.0以后，gradle的版本变成了4.1，改动特别大，因此升级要慎重，可是已经升级了，问题仍是得解决。

执行 gradle clean assembleRelease

是从这一行代码进行报的错，提示我说是在release合并资源的时候报错了，下面是具体的信息

下面最后一行开始报错

:app:generateAndroidReleaseResValues
:app:generateAndroidReleaseResources
:app:mergeAndroidReleaseResources

而后错误一直不断重复

AAPT err(Facade for 1119711668) : No Delegate set : lost message:\\?\C:\Windows\System32\config\systemprofile\.gradle\caches\transforms-1\files-1.1\appcompat-v7-25.4.0.aar\76d6a769daf730ed767830374ebcd3bd\res\drawable-hdpi-v4\abc_textfield_search_default_mtrl_alpha.9.png ERROR: Unable to open PNG file

追踪堆栈信息 --stacktrace --debug

* What went wrong:
16:04:41.129 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] Execution failed for task ':app:mergeAndroidReleaseResources'.
16:04:41.129 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] > Error: java.util.concurrent.ExecutionException: com.android.builder.internal.aapt.AaptException: 
16:04:41.129 [ERROR]

对吧，日志都出来了，看地我是一脸懵逼，只看懂了app:mergeAndroidReleaseResources。

漫长的debug之路

环境检查

个人项目在本地是成功编译过的，无论是debug仍是release都是OK的，clean也是没问题的，因此我当时就以为应该是服务端编译的问题，可是服务端的代码是从gitlab上面获取的，跟我本地的是如出一辙的，不该该有问题，难道是编译环境出了问题吗，由于上面的报错都是跟gradle相关的，因此我就打印了各自的gradle：

本地grade版本:

Gradle 4.1
------------------------------------------------------------

Build time:   2017-08-07 14:38:48 UTC
Revision:     941559e020f6c357ebb08d5c67acdb858a3defc2

Groovy:       2.4.11
Ant:          Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM:          1.8.0_131 (Oracle Corporation 25.131-b11)
OS:           Windows 10 10.0 amd64

服务端grade版本:

Gradle 4.1
------------------------------------------------------------

Build time:   2017-08-07 14:38:48 UTC
Revision:     941559e020f6c357ebb08d5c67acdb858a3defc2

Groovy:       2.4.11
Ant:          Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM:          1.8.0_131 (Oracle Corporation 25.131-b11)
OS:           Windows 10 10.0 amd64

是同样的，呵呵哒，只能再分析别的缘由了，其实这个时候是没有什么思路的，由于太诡异了，基本上什么都同样了，可是服务端就是编译不成功，我能怎么办，我也很绝望啊。而后就用Google搜索了一下，搜到的答案基本上都不是太相关，只好做罢。

目录对比

其实在对比环境以后当时就想着回退版本了，毕竟已经折腾了好久了，不过转念一想，程序员不就是为问题而生的吗，而后又冷静思考了一下子，还有什么是不同的，终于发现了，目录，服务端编译的目录跟本地的目录不同，但是这个在理论上是没有影响的，不过值得一试。而后我就直接打开了服务端在本地的项目，而后进行检查。

gradle clean

本地

E:\Jenkins\workspace\Test>gradle clean
> Configure project :app
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':app:clean'.
> Unable to delete file: E:\Jenkins\workspace\Test\app\build\intermediates\merged-not-compiled-resources\android\release\anim\abc_fade_in.xml

服务端

[Gradle] - Launching build.
[Test] $ cmd.exe /C "C:\Users\pangchao\.gradle\wrapper\dists\gradle-4.1-all\bzyivzo6n839fup2jbap0tjew\gradle-4.1\bin\gradle.bat clean && exit %%ERRORLEVEL%%"
:clean
:app:clean

BUILD SUCCESSFUL in 20s
2 actionable tasks: 2 executed
Build step 'Invoke Gradle script' changed build result to SUCCESS

是否是很意外，一个失败一个成功，并且竟然是本地失败，服务端成功，很诡异。

gradle assembleRelease

本地打包

E:\Jenkins\workspace\Test>gradle assembleMumayi
> Configure project :app
[E:\Jenkins\workspace\Test\app\build\outputs\mapping\mumayi\release\dump.txt]...
Removed unused resources: Binary resource data reduced from 559KB to 539KB: Removed 3%

BUILD SUCCESSFUL in 31s
51 actionable tasks: 49 executed, 2 up-to-date
E:\Jenkins\workspace\Test>

服务端打包

[Gradle] - Launching build.
:app:assembleMumayiRelease
:app:assembleMumayi
BUILD SUCCESSFUL in 7s
51 actionable tasks: 6 executed, 45 up-to-date
Build step 'Invoke Gradle script' changed build result to SUCCESS
Finished: SUCCESS

能够看到先由本地编译，而后再通过服务端编译时均可以成功的，可是以前咱们是先通过服务端编译时不能成功的，也就是说，咱们要先进入到服务端的目录本地成功编译一次以后，才能在服务端成功编译。最重要的一点是服务端打包之间不能进行clean，具体缘由我也不是很清楚，应该是跟AS 3.0升级的特性有关系，改天研究一下官方文档才能知道具体缘由，也就是说目前的状况以下：
也就是在AS3.0的基础上，若是我想在服务端自动构建apk，那么首先必须在本地成功编译一次，既然是这样，那么咱们干脆在本地先把全部渠道的Debug包Release包先统一编译一次，这样的话在服务端无论想要打哪一种包都是OK的，就这么愉快地决定了。

• gradlew clean
• gradlew build

这样就行了，剩余的操做跟以前的AS 2.X基本一致，OK，到此为止，AS 3.0也能够很轻松的使用jenkins，虽然折腾了好久，可是最终仍是解决了问题。

后续

集成过jenkins的小伙伴们可能知道，其实还有不少功能没有细说，好比说打完包后将安装包自动上传到fir或者蒲公英，生成一个二维码，发送邮件到指定的收件人，其实这些都比较好解决的，网上已经有不少教程了，并且这些均可以经过插件跟脚本实现，下面贴一下相关的插件，你们Google或者百度一下就能够搞定了，本文主要在于分析一下AS 3.0的继承问题，没有针对这些问题进行研究。

做者：wustor 连接：https://www.jianshu.com/p/55efb9407fa2 来源：简书 简书著做权归做者全部，任何形式的转载都请联系做者得到受权并注明出处。