いまさらかもしれませんが、werckerをはじめてみました。
使ってみると、思った以上に良さそうだったので紹介します。
目次
特長
werckerはこういったサービス(クラウド型のCI)には珍しくプライベートリポジトリも無料で無制限に扱えます。
動作の仕組みは、リポジトリへのpushをトリガとして設定ファイルをもとにDockerコンテナを実行させるようなイメージです。
werckerに登録する
werckerのサイトから、Get started for freeというボタンを押して、サインアップします。Githubのアカウントを持っていればそちらでもできます。
アカウントの登録が完了したら、アプリケーションの追加を行います。これは、GithubまたはBitbucketのリポジトリを参照して追加できます。Configure accessのところはデフォルトのままでいいと思いますが、最後のステップで「Make my app public」にチェックを入れるとパブリックになってしまうのでプライベートのままにしたい場合はチェックが外れた状態なのを確認してFinishします。
私のプロジェクトの場合
公式サイトのDocumentにも例やサンプルなど書いてあるのですが、意外とそのままではすんなり動かない・・・。
いろいろとポイントがありますので順を追って書いていきます。
wercker.ymlはルートディレクトリにないといけない
例えば、以下のようなツリーでリポジトリにコミットしている場合...
myproject ├── backend │ └── api │ └── src │ └── app └── frontend ├── android └── ios
backendは、GOでandroidはJava,iOSはSwiftでのプロジェクトとすると各サブプロジェクトごとにwercker.ymlを置いて実行、とかしたいのですができません。
リポジトリの直下(ここでいうとmyprojectの直下)に配置しなければなりません。
なので、上記のような場合はbackendとandroid、iosそれぞれを別のリポジトリにしてsubmoduleとして全体の俯瞰用のリポジトリから読む感じにした方が良さそうです(が、今回そこまでできなかったので、この構成でbackendの処理をさせます^^;)
Dockerコンテナからのソースの参照場所は?
これがドキュメントを見てもさっぱり分かりませんでした。
いろいろ調べてみると、/pipeline/source というところにあるようでしたが、このパスをそのまま使うのも嫌な感じしかしません。
さらに調査を進めると、このパスはWERCKER_SOURCE_DIRという環境変数にセットされているようでした。
step-setup-go-workspace
公開されているstep(werckerでの処理単位のこと)にsetup-go-workspaceというものがあります。
これは、WERCKER_SOURCE_DIR内のファイルをGOPATH環境変数下にコピーしてコピー先にWERCKER_SOURCE_DIRを変更するものです。
これを利用して、$WERCKER_SOURCE_DIR/backend/api/src/app以下のファイルを/go/src/appに配置し、WERCKER_SOURCE_DIRを/go/src/appに再設定してみます。
wercker.yml
以下のようなwercker.ymlを作ります。
box: golang build: steps: - script: code: | export WERCKER_SOURCE_DIR="$WERCKER_SOURCE_DIR/go/src/app" - setup-go-workspace: package-dir: app - wercker/golint: exclude: "vendor"
setup-go-workspaceは、WERCKER_SOURCE_DIRのファイルを/go/src/{package-dir}にコピーして、WERCKER_SOURCE_DIRを/go/src/{package-dir}に変更するので、これでうまくいきそうです。
ちなみに、このままではgo guildとかgo testを入れていないのでlintまでしかやってくれませんw
実行してみる
werckerには、CLIというのがあってローカルでDockerを使ってビルドを行うことができます。Docker Machineのセットアップが既にできていれば、Homebrewからインストールするだけで使えます。
$ brew tap wercker/wercker $ brew install wercker-cli
インストールできたら、wercker.ymlがある場所で以下のコマンドでローカルビルドができます。
$ wercker build
buildのほか、devというパイプラインを定義しておけば、実行できるようです(これを使うと、godoを使ったファイル監視+ビルドと似たようなことができるみたいです)。
また、wercker.ymlをプッシュすると自動的にサーバ側のbuildが走ります。
問題点
ちょっとまだできていない点として、このままビルドやテストのコマンドを入れてもglideのインストールとかglide upを入れていないのでwerckerサーバ上で実行されるとgo getされて期待されているパッケージとバージョンが異なってしまう可能性があります。
scriptステップで全部やるか、glideを入れたDokcerイメージをDocker Hubにpullしておいて使ってもいいかもしれないです。ちょっとそのあたりはまた後日試してみたいと思います。
感想など
まだちょっと触っただけで全然使いこなせてはいませんが、リポジトリのPushのタイミングで任意のDockerコンテナを使ってリポジトリ内のコードを処理させることができるというのはテストだけではなく、かなり色々な可能性を秘めていると感じました。
これから本格的に使ってみたいですね。