前置き
Wercker は Docker コンテナの中で CI をするサービスで、とりあえずビルドに必要な環境が整った Docker イメージがあれば、あとは Wercker が勝手にイメージを引っ張ってきてコンテナを立ち上げて指示通りビルドをしてくれるため、公式ドキュメントにはない Android アプリのビルドも可能です。
ビルドに必要な環境はすべて Docker イメージにまとめて放り込んでしまえるので、SDK の更新があったときに CI サービス側の対応を待たなくとも、自分でイメージを作り直すだけで環境を最新に保つことができる点が魅力ですが、裏を返せば自分で環境をメンテナンスしなくてはならないという面倒臭さがあります。
とは言え、CI サービス側が環境を用意してくれる場合でも、自分で環境をメンテナンスする場合でも、環境が新しくなってもビルドが壊れないことの確認は最低限する必要があることに変わりありません。そう考えると、自分で環境のメンテナンスをするほうが、環境のポータビリティに歩があり、新しい環境でのビルドのチェックもし易いような気がします（CIサービス側が環境を用意してくれる場合、sshでビルドサーバに繋いで状況を確認することができればさほど違いはないかもしれませんが）。
更新時の手順
1. Docker イメージをビルドする
何を置いてもまずは Docker イメージをビルドします。
Android アプリのためのビルド環境の場合で、かつ Dockerfile でイメージを構築している場合、Support Repository や Google Repository のアップデートなど、Dockerfile に記述する手順に変更のない更新が稀によくあります。Dockerfile の変更がないとキャッシュを使ってビルドしてしまうため、この条件に当てはまる場合は、キャッシュを使わずにビルドしたり、キャッシュをパージしてビルドしたりする必要があります。
キャッシュを使わずに新しくイメージをビルドする場合は
$ docker build -no-cache -t image_name:tag .
キャッシュをパージする場合は
$ docker rm $(docker ps -a -q)
$ docker rmi $(docker images -q)
$ docker build -t image_name:tag .
でイメージをビルドします。古いイメージを残す必要がなければ、毎回キャッシュをパージしてしまったほうがディスクスペースの節約になります。
2. Docker コンテナを立ち上げてアプリをビルドする
イメージのビルドが終わったら、コンテナに入って新しい環境でアプリがビルドできるかを確認します。
$ docker run -it image_name:tag /bin/bash
#
イメージの中には GitHub 用の ssh 鍵がない場合も多いでしょう。その場合は、GitHub の Personal Access Token を使って認証します(Personal Access Token の取得は、GitHub の設定画面からできます)。git clone後に聞かれるユーザ名は GitHub のユーザ名、パスワードに Personal Access Token を設定します。
# git clone https://github.com/Hoge/fuga.git
Username for 'https://github.com': YourName
Password for 'https://github.com': YourPersonalAccessToken
あとはクローンできたらいつものコマンド(wercker.ymlにある手順)を叩くだけです。
3. docker push
確認が終わったら忘れずにプッシュしましょう。
DockerHub でイメージのリビジョン管理をする場合、タグを活用するとよいです。常に latest にしてしまうと、アプリでブランチを分けたあとでイメージが更新されたときに、そのブランチの CI も最新イメージで実行されるため、何もしていないのに急にビルドが壊れる恐れがあります。
何をタグとして用いるかは難しいものですが、Dockerfile を git 等で管理する場合は、どのコミットの時点でビルドしたのかを表せるようハッシュ値をタグに設定する方法が考えられます。ただしこれだけだと、前述したような Dockerfile の変更を伴わない更新に対応できません。素直に support-rep-38 とかどのリビジョンのリポジトリが含まれているかをタグに書くなどしましょう。
さいごに
Wercker はいいぞ