搭建Jenkins
介绍
Jenkins是一种CI(Continuous integration,即可持续集成)系统工具。简单来说就是用于持续、自动地构建/测试软件项目和进行监控。具体来说的话,它可以实现
- 软件构建自动化 :配置完成后,CI系统会依照预先制定的时间表,或者针对某一特定事件,对目标软件进行构建。
- 构建可持续的自动化检查 :CI系统能持续地获取新增或修改后签入的源代码,也就是说,当软件开发团队需要周期性的检查新增或修改后的代码时,CI系统会不断确认这些新代码是否破坏了原有软件的成功构建。这减少了开发者们在检查彼此相互依存的代码中变化情况需要花费的时间和精力。
- 构建可持续的自动化测试 :构建检查的扩展部分,构建后执行预先制定的一套测试规则,完成后触发通知(Email,RSS等等)给相关的当事人。
- 生成后后续过程的自动化 :当自动化检查和测试成功完成,软件构建的周期中可能也需要一些额外的任务,诸如生成文档、打包软件、部署构件到一个运行环境或者软件仓库。这样,构件才能更迅速地提供给用户使用。
Jenkins的主要目标是监控软件开发流程,快速显示问题,保证开发人员以及相关人员省时省力提高开发效率,其还有以下特性
- Jenkins一切配置都可以在web界面上完成。有些配置如MAVEN_HOME和Email,只需要配置一次,所有的项目就都能用。当然也可以通过修改XML进行配置。
- 支持Maven的模块(Module),Jenkins对Maven做了优化,因此它能自动识别Module,每个Module可以配置成一个job。相当灵活。
- 测试报告聚合,所有模块的测试报告都被聚合在一起,结果一目了然,使用其他CI,这几乎是件不可能完成的任务。
- 构件指纹(artifact fingerprint),每次build的结果构件都被很好的自动管理,无需任何配置就可以方便的浏览下载。
- 插件支持,支持扩展插件,你可以开发适合自己团队使用的工具。
安装
JDK
在安装2.74版本的Jenkins前,首先需要安装JDK8。
10.12的Mac系统自搭载的JDK版本是1.7.0_73(即是JDK7)。
java -version
在终端使用上面指令可查看JDK的具体版本信息。安装完JDK8后,再使用该指令查看,会发现仍然显示JDK7的版本信息,这里就需要做一点小的调整才能把JDK版本由当前系统搭载的版本切换到自定义下载的版本。
which java
首先,使用上面指令查看现在java软件包的来源是 /usr/bin/java
,在该路径下发现这java是一个替身,真正的位置是 /System/Library/Frameworks/JavaVM.framework/Version/A/Commands/java
,这个framework就是系统自搭载的JDK了。
然后,输入以下指令进行当前使用版本的切换,用ln创建替身的源参数就是自定义下载的java所在位置,切换前也可以先验证替换的版本号。
/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java -version
sudo rm /usr/bin/java
sudo ln -s /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java /usr/bin
同时在~/.bashrc中添加下面一行。
export PATH=/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin:$PATH
并执行以下指令,重载bashrc文件。
source ~/.bashrc
但是,在10.12的MacOS上,你可能无法完成移除 usr/bin/java
,因为新版的Mac系统为了防止系统软件被篡改,禁止了直接对 usr/bin
的操作,甚至乎是root权限。需要将切换版本的指令改为
sudo ln -s /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java /usr/local/bin
这样就覆盖了系统原有的(/usr/bin/)java程序。
/usr/bin
是用于存放系统管理的用户程序,/usr/local/bin
是用于不受系统管理的普通用户程序,未来的系统更新可能会更改会没有警告地删除 /usr/bin
中的内容,这存放用户程序的方案叫Package Management
。
最后,再执行上面查看当前JDK版本信息的指令,就应该显示为1.8.0_144(macOS Sierra 10.12.4上)。
Jenkins
2.74版本的Jenkins,下载好pkg包后,按提示逐步安装,这个过程非常简单,也可以通过下载jenkins.war
,运行 java -jar jenkins.war
进行安装。
安装完毕后,Safari会自动打开,或者自己在浏览器中输入 http://localhost:8080
即可进入Jenkins的配置页面。
如果输入地址后报错“Safari can’t connect to server”,那可能是一些启动设置还没好,下面说一下遇到的问题点。
启动配置文件的权限不足
这是问题是在一台搭建了Jenkins的服务器升级系统版本时遇到的,系统版本由10.11升到10.12后,Jenkins就无法启动了,解决贴在这。原因就是新的MacOS Sierra改变了Jenkins文件夹的权限,按以下步骤输入指令即可搞定。sudo chmod u+x /Library/LaunchDaemons/org.jenkins-ci.plist sudo chown jenkins /var/log/jenkins sudo launchctl load /Library/LaunchDaemons/org.jenkins-ci.plist
服务进程没有开启
通过以下两条指令可以控制服务进程的开关sudo launchctl load /Library/LaunchDaemons/org.jenkins-ci.plist sudo launchctl unload /Library/LaunchDaemons/org.jenkins-ci.plist
Jenkins使用的Java环境配置不对
首先需要系统支持Java并已经安装好Java8,其次需要在/Library/Application Support/Jenkins/jenkins-runner.sh
中添加以下一行
export JAVA_HOME=”/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home”
和修改最后两行成
echo “/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java” $javaArgs -jar “$war” $args
exec “/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java” $javaArgs -jar “$war” $args
配置
谢天谢地,终于看见Jenkins的UI。
用户
安装完Jenkins后,偏好设置中的用户会发现多了一个没有名字的用户,属性为普通成员。
这个时候,将锁解除,重新设置该账号的信息(鼠标右键-高级选项-全名:设置用户名),这就是拥有Jenkins文件夹绝对权限的用户,之后在模拟器上Build项目都必须登录到该用户的账号下才能正常运行,因为在后台可以运行Jenkins、Xcode,但不能运行模拟器。
Server
回到Jenkins Server上,配置的第一页让我们输入Admin的初始密码,页面上有提示密码所在的路径 /Users/Shared/Jenkins/Home/secrets/initialAdminPassword
,如果当前登入账号不是Jenkins,则修改一下该文件的权限,再打开获取密码填入即可。
之后在创建Admin时或者进入到操作界面记得把密码改回来就是了,因为这初始密码不是给人记的。
接下来一路就是
- 安装默认插件
- 创建Admin账号(用户名、密码、全名、邮箱)
如果有插件安装失败,先重试一下。
最后来到主界面,有以下菜单项
常用的有以下几项
- 新建:创建新的Item进行自动化的构建操作;
- 用户:设置可在当前安全域中登录的用户;
- 任务历史:列出构建过的所有记录,并有甘特图辅助观察;
- 系统管理:系统的全局设置,插件管理,用户管理,系统日志等等都在这里找到;
- 我的视图:可以将Item分配到不同的视图中进行相对分组;
- 凭证中心:用于Item中管理操作时,需要用到的账号、token、证书等验证信息时,可以从该凭证中心直接获取。是一个统一配置各种凭证的地方,可以查看各个凭证所用于的Item。
插件
在系统管理下,可以进行全局的设置、管理插件、管理日志等
选择系统管理->管理插件->可选插件
,就可以安装一些辅助插件,当时安装了这些:
- GitLab Plugin
- GitLab Hook Plugin
- Xcode integration
- Email Extension Plugin
Item
创建好的Item会在主界面上直接看到
包括
- S(tatus):最后一次构建的状态,成功呈蓝色,失败呈红色状;
- W(eather):如果一直失败就是狂风暴雨,大部分成功偶尔失败则是晴到多云,每次都成功则是晴天;
- Name:Item的名称;
- Last Success:最后一次构建成功的时间及编号;
- Last Failue:最后一次构建失败的时间及编号;
- Last Persistent Time:上次构建持续的时间。
在Item里,有以下内容
- 状态:可查看工作区和最新修改记录,和历史构建记录的链接;
- 修改记录:Git上新Push的版本;
- 工作空间:即是工作区,可以查看Git上Check out下来的最新版本(相对于最后一次执行poll scm)的文件;
- 立即构建:手动执行构建;
- 删除Project:将Item移除;
- 配置:内容包含构建前后的操作、构建的触发器和环境、源码管理等等;
- Git Polling Log:轮询Git的日志。
配置Item是Jenkins里最重要的一个环节之一,它直接影响构建的执行,接下来就以Build Xcode Unit Test为例子,详细说一下如何配置一个Item。
创建
首先创建一个freestyle的软件项目构建Item。
常规设置
丢弃旧的构建
,勾选了就可以控制构建保留的天数和最大个数,除此之外还可以在高级
里配置包的保留天数和个数;参数化构建过程
,第一种用法是相当于预设环境变量,第二种用法是指定文件;节制构建
,控制构建的频率,例如一个小时最多只能构建一次;关闭构建
,顾名思义,勾选了该Item下的Project就不会执行构建;必要时并发构建
,一般情况下只会有一个构建在执行,其它构建请求会在构建队列中排队,但这项勾选了,在资源足够的情况下就会采取并发构建。
源码设置
None
:没有源码时勾选。Git
:使用Git管理版本的勾选。需要填写好Repository URL和Credentials。Branch Specifier默认是master,即是只构建master分支上的版本,留空则会构建所有分支。
由于当时使用的GitLab没有开启SSH功能,所以并没有在Credentials中配置SSH Username with private key的凭证,而采用原始的Username with password。
如果填写Repository URL后报错,说明没有连通Git或者SVN,要再检查一下SSH Key或者User name和password。Subversion
:使用SVN管理版本的勾选,和Git类似。
触发器设置
触发远程构建
:当你想通过一个指定的远端来触发一个新的构建,就得使用这项实现。例如在Git远端配置hook,推送地址按格式 JENKINS_URL/job/utility/build?token=TOKEN_NAME 填写。 这样Jenkins就能获取repository的所有commit通知。Build after other projects are built
:等待其它Project构建完再构建。如果上面勾选了并行构建,同时勾选该选项的话,意味着该Item下的构建会按顺序执行,但和其它Item的构建则是并行关系。Build periodically
:定期构建,不管Git上是否有版本更新。时间格式如下- 第一位代表分钟(0-59)
- 第二位代表小时(0-23)
- 第三位代表日期(1-31)
- 第四位代表月份(1-12)
- 第五位代表周(0-7,0和7代表周日)
如果你想每5分钟构建一次,则*/5 * * * *
(注意空格,/代表每),如果你想每天8点构建,则0 8 * * *
或者H 8 * * *
。H
和0
的区别是,H H * * *
代表每天构建一次且不与其它Item的构建时间点错开,即H
代表一个随机值,而0 0 * * *
则会扎堆在午夜0点爆发。
Build when a change is pushed to GitLab
:和第一项作用一样,不确定是否安装GitLab hook插件时生成的项。GitHub hook trigger for GITScm polling
:和上面一项一样,只是针对GitHub而已。Poll SCM
:定期检查新版本,有新版本则check out并执行构建,没有则等待下次检查。时间格式和Build periodically
中介绍的一样。
环境设置
这些看标题就能大概了解其作用,不多赘述。
构建设置
构建中可以选择不同的操作方式,包括Xcode、Execute Shell等,如下图
选择Xcode的话需要设置构建的Target、Code signing、Build options等。
这里简单演示了Execute Shell的构建方式。你可以在脚本中获取各种环境变量,点击Command框下的链接就有参考。因为该shell脚本所在的路径为 /Users/Shared/Jenkins/Home/workspace/utility
,所以先cd
到xcworkspace所在的路径再构建。下面构建的是一个Unit test的scheme
pwd
cd Example
xcodebuild test -workspace EfunUtilityModule.xcworkspace -scheme EfunUtilityModule_Tests -destination 'platform=iOS Simulator,OS=10.3.1,name=iPhone 7'
额外说明,在Item里面,构建开始后,构建历史列表中会显示当前构建的进度,点击编号可进入构建记录。在构建记录中,最常查看的是Console Output
,可以观察终端的所有log。
构建后设置
构建后可以添加一些可选性的后续操作,如下图
这里暂时只用到了发送通知邮件的功能
Content type: HTML (text/html)
Default content: ${SCRIPT, template=”groovy-html.template”}
使用邮箱功能,先在全局设置那完成基本配置
- 先登录到个人邮箱,“设置”->“POP3/SMTP/IMAP”设置授权码,然后将授权码填入密码项,因为有些邮箱不允许直接从第三方使用帐密操作;
- 设置SMTP服务器,提醒一下,有些官方提供的服务器域名也不一定准确,如果没效就再多找找确认;
- 设置用户默认邮件后缀,这个提示可选,但一般都填上;
- 选择SSL协议的话一般对应465的SMTP端口。有些邮箱可能不支持SSL或者端口不一样。
常见问题
然后回到Item里面的构建后设置,添加“邮件通知(Mail Notifcation)”的操作后,设置好“接收人(Recipients)”,多个接收人时用英文空格分隔(这里设置了接收人可以用全局变量获取之前全局设置的接收人,也可以重新指定覆盖掉全局的),最后可设置发送的触发条件”总是发送“或者”失败时发送“,另外还有两个附加选项:
- “每次不稳定的构建都发送邮件通知”是默认选项,当构建后结果失败或不稳定时发邮件给
Recipients
; - “单独发送邮件给对构建造成不良影响的责任人”,即是向最后提交Git版本的人发通知,Jenkins会根据设置的Recipients的默认邮箱后缀加上提交版本的用户名作为邮箱地址。
问题小结
这里遇到了一些坑
- 使用pod的一些工程,scheme默认是不在xcworkspace上的,而在xcproject上,需要在Xcode的Manage schemes中更改Scheme所在的位置和设置为share状态。
- workspace参数不能用绝对路径,
cd
到对应路径下使用相对路径就好了。 - 电脑一定要在Jenkins账号下登录才能调出模拟器,否则构建失败。
- RSA加解密和获取Bundle Seed ID的测试用例上,同为Xcode8,不同的小版本却测试出不一样的结果。
本文暂时只介绍了自动测试,分包的部分日后再补充吧。
参考文章
Testing with Xcode
一步一步构建iOS持续集成:Jenkins+GitLab+蒲公英+FTP
Continuous Integration in iOS using JENKINS
Jenkins入门系列
转载请注明来源,欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论,也可以邮件至 mingfungliu@gmail.com
文章标题:搭建Jenkins
文章字数:4k
本文作者:Mingfung
发布时间:2017-08-26, 22:59:36
最后更新:2019-11-21, 11:06:23
原始链接:http://blog.ifungfay.com/uncategorized/搭建Jenkins/版权声明: "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。