从Travis回GitHub

图片来源于GitHub Help

Deployment

Deployment一般直译为部署，本是一个军事名词。在被新兴的软件工程借用后，现在多是用来指软件开发的一些后续过程，如发布、安装与激活、适配、更新等，详见维基百科Software_deployment。

本文主要介绍如何用Travis，把自动编译后的某些文件，自动deploy到GitHub的Releases里。（以下均以“发布”来代称deploy与deployment。）

如果你还没用过GitHub Releases，可以自补官方文档：https://help.github.com/categories/releases/

自动发布配置

示例如下：

language: groovy

jdk:
  - oraclejdk8
  - openjdk7

script: "./gradlew build"

before_deploy:
  cp $TRAVIS_BUILD_DIR/build/libs/ARTIFACT_ID*.jar ARTIFACT_ID.jar

deploy:
  provider: releases
  skip_cleanup: true
  file: "ARTIFACT_ID.jar"
  api_key:
    secure: "KmMdcwTWGubXVRu93/lY1NtyHxrjHK4TzCfemgwjsYzPcZuPmEA+pz+umQBN\n1ZhzUHZwDNsDd2VnBgYq27ZdcS2cRvtyI/IFuM/xJoRi0jpdTn/KsXR47zeE\nr2bFxRqrdY0fERVHSMkBiBrN/KV5T70js4Y6FydsWaQgXCg+WEU="
  on:
    tags: true
    jdk: oraclejdk8

# vim: set shiftwidth=2 tabstop=2 softtabstop=-1 expandtab:

script以前的内容，上篇已经介绍了。下面介绍之后的配置：

before_deploy
在发布前，把编译好的jar改名，放在容易伸手的地方。（我不确定下面的file字段是否支持通配符。）
deploy
发布配置的主体。
- provider
  指定发布到哪里，这里releases就是指GitHub Releases。
  目前（2016年），Travis支持GitHub Releases、bintray、Google App Engine、npm、PyPI、RubyGems等，约30种发布方式。
- skip_cleanup
  由于Travis很可能执行到这一步时，会清理掉之前编译的部分过程文件，其中就有可能包含要上传的那些。所以这一条通常设置为true。
  不过，在本例中，在before_deploy中就已准备好要上传的jar文件，这一条其实未起作用。
- file
  指定要上传到GitHub Releases的文件。可以指定多个文件。
- api_key
  GitHub特有的认证字段，可用账户密码代替，必须要加密。下面几个小节会介绍如何加密。
  实际上，整个配置的难点就在这里，其它字段都没有什么理解、配置上的难度。
- on
  条件发布（Conditional Releases）的指定。显然，发布这种事情，不是每次提交、每个分支都应该做的。
  除了下面两类外，还可以指定repo（不影响fork出去的库）、branch（默认为master）、以及condition（自定义条件）。
  - tags
    每次有新的git tag被提交时，GitHub都会自动生成一个release，默认带上源码的压缩包，这是本身就有的机制。
    所以，对Travis来说，在每次打tag时触发一次deployment，是比较合适的时机。
  - jdk
    这个项目虽然在两个JDK下分别进行编译、测试，但其实只需要在一个JDK下发布。
    同类的条件还有python、node等。

私有信息加密

由于Travis的运作，依赖于纯文本的.travis.yml配置文件，所以对public或有可能某一天变成public的项目来说，任何私密信息都不应该放在其中。

这是所有利用第三方CI时，都需要注意的信息安全问题。开源，分享的是文档、代码和创意，而不是银行账户。

Travis显然早已留意了这个问题，给出了加密方案。加密后，大致形式如下：

secure: "KmMdcwTWGubXVRu93/lY1NtyHxrjHK4TzCfemgwjsYzPcZuPmEA+pz+umQBN\n1ZhzUHZwDNsDd2VnBgYq27ZdcS2cRvtyI/IFuM/xJoRi0jpdTn/KsXR47zeE\nr2bFxRqrdY0fERVHSMkBiBrN/KV5T70js4Y6FydsWaQgXCg+WEU="

（注：这个secure拷贝于Travis某介绍文档。我实际使用的加密文本更长些。）

也就是把明文字段，加密成上面的模样，再放到配置文件.travis.yml中。

具体的保密原理，可见官方文档：《Encryption keys》。

安装travis.rb

为了实现加密功能，需要安装Travis的命令行客户端（Command Line Client），它就是GitHub上的travis-ci/travis。它既是一个基于Ruby的命令行程序，也是一个Ruby的库。

通常，使用gem install travis即可安装。

在中国，由于rubygems.org不够给力（也许可以换种说法），有时根本没法用，所以我们需要更给力的镜像。

ping rubygems.org如果没有好的结果，那么可以用https://ruby.taobao.org/。该镜像承诺每15分钟同步一次，可以解决大多数问题，装个travis显然没问题。（而且，看在逢年过节都大出血的份上，谢一声后，就可以心安理得地尽情使用。）

gem sources --add https://ruby.taobao.org/ --remove https://rubygems.org/

替换后，再执行前述安装命令，即可快速成功安装。

travis命令简介

任何一个网络服务的客户端，完整功能都需要先登录再使用，哪怕它是一个shell命令也一样。

最简单的上手是，执行travis login，根据提示输入GitHub账户、密码登录后，就可以正式开始使用了。但这有个权限过大的问题，它可以对GitHub进行完全控制，所以官方推荐另一种更好的登录方式：指定token。

travis login其实并未把账户密码发送到travis-ci.org，而是发给github.com，生成了一个完整权限token。它承诺，没有把账户密码发送到自家服务器，安全可靠。原理可见文档：travis.rb#login。

不过，这个token其实也是GitHub生成的，专门提供给第三方来调用。可以去GitHub上自己生成（见下一小节），然后用travis login --github "TOKEN"，可直接登录。

正式使用时，当前目录最好就是项目的根目录，这样travis可以自动识别需要处理的项目，省去很多麻烦。

登录后，在项目的根目录，开始加密：

travis encrypt "TOKEN" --add deploy.api_key

--add可以自动把加密好的内容放到.travis.yml文件的指定字段。也可省略这个参数，拿到secure密文后自行配置。

（注：这个token可以是和登录时的那个相同，也可以不同。）

另外，source ~/.travis/travis.sh后，travis命令就支持补全了。可以把这一行加到.bashrc或之类的shell配置文件中。

更多的使用教程，可以看其README，或执行travis -h。

熟练使用后，基本可以不登录网站了。

生成GitHub的token

作为第三方CI，无论是发布到GitHub、还是其它地方，都需要足够识别身份的私密信息，或是账户密码，或是某种key。

GitHub里用的就是Personal access tokens。

在这个页面可以生成一个token，并可修改相关权限。对公开项目Travis需要的权限如下：

user:email (read-only)
read:org (read-only)
repo_deployment
repo:status
write:repo_hook

相关介绍，可见官方文档：《Travis CI's use of GitHub API Scopes》。

验证

配置完毕后，打上tag，然后git push --tags就可触发。

由于.travis.yml的配置开始复杂起来，所以大改后，为避免语法错误，最好先做验证，再提交。可以选择：

在线验证：http://lint.travis-ci.org/
本地验证：travis lint .travis.yml

参考

Travis官网文档：https://docs.travis-ci.com/

上一篇：《从GitHub到Travis》
下一篇：《从Travis到bintray》

后记

匿：为什么不直接去发布，搞这么麻烦的配置文件？
蟒：我懒嘛！而且，据说优秀的程序员都懒，什么都要尽量自动化。
匿：有折腾这些的时间，你那小项目早就发布了，而且够手动发布一百回。这项目，你打算发布几百次？
蟒：……