随着Xcode 8的发布,Apple引入了一种管理签名配置的新方法。现在,您有两个选择Manual
和Automatic
。
根据有关代码签名的WWDC 2016会议(WWDC
2016-401-Xcode应用程序签名的新增功能)
,当您选择Automatic
签名时,Xcode将执行以下操作:
但是根据苹果在那届会议上所说,它将被Automatic Signing
使用,Development signing
并且将仅限于Xcode创建的配置文件。
当您尝试Automatic Signing
在CI环境(例如Travis
CI或Jenkins)上使用时,就会出现问题。我无法找到一种简单的方法来继续使用“自动”并签署分发文件(因为Xcode会迫使您使用Development和Xcode创建的配置文件)。
新的“
Xcode创建的供应配置文件”未显示在开发人员门户中,尽管我可以在我的机器中找到……我是否应该将这些配置文件移至CI机器,为其构建Development
并导出Distribution
?有没有办法覆盖Automatic Signing
使用xcodebuild
?
在尝试了一些选项之后,这些是我可以在CI服务器上使用的解决方案:
使用会Automatic signing
强制您使用Developer
证书和auto-generated provisioning profiles
。一种选择是将开发证书和私钥(应用程序->实用程序->钥匙串访问)以及自动生成的配置文件导出到CI机器。定位自动生成的配置文件的一种方法是导航到~/Library/MobileDevice/Provisioning\ Profiles/
,将所有文件移动到备份文件夹,打开Xcode并存档项目。Xcode将创建自动生成的开发配置文件,并将其复制到Provisioning Profiles
文件夹中。
xcodebuild archive ...
将为创建一个.xcarchive
签名Development
。xcodebuild -exportArchive ...
然后可以将构建辞职Distribution
拨打电话之前xcodebuild
解决方法是更换的所有实例ProvisioningStyle = Automatic
与ProvisioningStyle = Manual
在项目文件。sed
可用于在pbxproj
文件中简单查找替换:
sed -i '' 's/ProvisioningStyle = Automatic;/ProvisioningStyle = Manual;/' <ProjectName>.xcodeproj/project.pbxproj
@thelvis还使用html" target="_blank">gem
创建了一个Ruby脚本来完成此任务xcodeproj
。该脚本使您可以更好地控制更改。
xcodebuild
然后将使用CODE_SIGN_IDENTITY
项目中设置的代码签名身份()以及供应配置文件(PROVISIONING_PROFILE_SPECIFIER
)。这些设置也可以作为参数提供xcodebuild
,它们将覆盖项目中设置的代码签名标识和/或供应配置文件。
编辑:使用Xcode
9,xcodebuild
有一个新的构建设置参数CODE_SIGN_STYLE
可供选择Automatic
,Manual
因此无需在项目文件中查找和替换自动实例为手动,WWDC
2017 Session
403中的更多信息Xcode和Xcode
Server签名中的新增功能
手动签名将完全控制所使用的代码签名标识和配置文件。这可能是最干净的解决方案,但缺点是失去了自动签名的所有优点。
要了解有关使用Xcode
8进行代码签名的更多信息,我真的推荐这篇文章以及WWDC2016会议401-Xcode应用程序签名中的新增功能
Electron 基于 Chromium,所以需要一个显示驱动使其运转。 如果 Chromium 无法找到一个显示驱动, Electron 会启动失败,因此无论你如何去运行它,Electron 不会执行你的任何测试。 在 Travis,Circle, Jenkins 或者类似的系统上测试基于Electron的应用时,需要进行一些配置。 本质上,我们需要使用一个 虚拟的显示驱动。 Testing o
Electron 基于 Chromium,所以需要一个显示驱动使其运转。 如果 Chromium 无法找到一个显示驱动, Electron 会启动失败,因此无论你如何去运行它,Electron 不会执行你的任何测试。 在 Travis,Circle, Jenkins 或者类似的系统上测试基于Electron的应用时,需要进行一些配置。 本质上,我们需要使用一个 虚拟的显示驱动。 配置虚拟显示服务器
检查当前环境是否是Travis CI。 检查当前环境是否具有TRAVIS和CI环境变量(reference)。 const isTravisCI = () => 'TRAVIS' in process.env && 'CI' in process.env; isTravisCI(); // true (if code is running on Travis CI)
Overview 平时项目里用的是jenkins,但很难找到好用又免费的jenkins hosting服务,而travis-ci.org免费为github用户提供服务且非常易用,SpringSide的地址为 https://travis-ci.org/springside/springside4 。不过商业的项目就没这么幸运了,两个并发要129美刀/月,十个并发要489美刀,不过其实也不贵。 Qu
在 Travis CI 中使用 Docker 当代码提交到 GitHub 时,Travis CI 会根据项目根目录 .travis.yml 文件设置的指令,执行一系列操作。 本小节介绍如何在 Travis CI 中使用 Docker 进行持续集成/持续部署(CI/CD)。这里以当代码提交到 GitHub 时自动构建 Docker 镜像并推送到 Docker Hub 为例进行介绍。 准备 首先登录
Travis CI 是一个基于云的持续集成项目, 目前已经支持大部分主流语言了,比如:C,PHP,Ruby,Python, Nodejs等等。和Jenkins类似, Travis CI也是开源的,不过Travis和Github集成非常紧密,官方的集成测试托管只支持Github项目, 不过你也可以搭建一套自己的方案。 如果你有开源项目,那么Travis绝对值得一试,目前托管在Github上的大部分