Walter の改良まとめ
伊藤（takahi_i）
ATL の takahi_i です。
ちょうど一年ほど前 Walter というビルドパイプラインツールをリリースしました。それからゆっくりとはですが、いまでも開発が続けられています。このブログエントリではリリース時から Walter がどう改良されてきたかについて解説します。改良されたポイントはいくつかの種類に分けられます。以下の節で各項目について解説します。
- 環境変数の利用
- ステージで利用できるプロパティ（directory, only_if）のサポート
- cleanup パイプラインの追加
- 定義済みステージの再利用
- ステージ結果の再利用
環境変数の利用
Walter のパイプライン上で環境変数を利用できるようになりました。環境変数はパイプライン設定ファイルで $VAR という表記をします。環境変数は walter コマンドの実行時に設定されているものが利用できます。たとえば、以下のコマンドでは環境変数 GOPATH の内容をを出力しています。
|
1 2 3 4 |
pipeline: - name: print GOPATH command: echo $GOPATH |
以下の設定のように、HipChat の通知に必要なキーなどのリポジトリに登録したくない情報を環境変数として記述することで安全性を向上できます。
|
1 2 3 4 5 6 |
messenger: type: hipchat2 room_id: $HIPCHAT_ROOM_ID token: $HIPCHAT_TWO_TOKEN from: $HIPCHAT_USER_NAME |
ステージで利用できるプロパティ（directory, only_if）のサポート
Walter では pipeline ブロックにステージのリストを追加して、処理を記述します。通常 Walter のステージにはコマンド（command） とステージ名（name）のみを指定します。たとえば以下のパイプラインに追加されたステージは “show the files” という名前と、コマンド （ls -la) が指定されています。
|
1 2 3 4 |
pipeline: - name: show the files command: ls -la |
新たに追加されたステージ用のプロパティを指定することでコマンドの実行の条件や実行するディレクトリを指定できます。
only_if
only_if は指定された条件がみたされたときにステージを実行します。以下の例では環境変数 WERCKER の値が true に設定されたときのみ command で指定されたコマンドが実行されます。
|
1 2 3 4 |
pipeline: - name: Put SSH public key command: echo $PUBLIC_SSH_KEY > $HOME/.ssh/id_rsa.pub only_if: test "$WERCKER" = "true" |
directory
directory はコマンドを実行するディレクトリを指定します。たとえば以下の ls ステージは /usr/local のファイル一覧を表示します。
|
1 2 3 4 5 |
pipeline: - name: show /usr/local files command: ls -la directory: /usr/local |
cleanup パイプラインの追加
新しく追加された cleanup パイプラインは処理を定義します。具体的には cleanup は pipeline に記述された処理が実行後に実行されます。以下の pipeline ブロックは input.data というファイルを Apache Solr の入力フォーマットに変更した後、データを登録しています。pipeline を実行した後 cleanup パイプラインが動作します。以下の例では Solr の入力用に生成したデータを削除しています。
|
1 2 3 4 5 6 7 8 9 10 |
pipeline: - name: create data command: create_solr_data.rb -i input.data -o output/solr-data.xml - name: register data command: $SOLR_HOME/bin/post -host $SOLR_HOST -port $SOLR_PORT -c car-instance -o output/solr-data.xml cleanup: - name: cleanup xml data command: rm -f output/solr-data.xml |
定義済みステージの再利用
Walter で定義したステージを再利用したいという声をもらいました。そこでステージ定義を含むファイル（ステージ定義ファイル）をインポートする仕組みをサポートしました。
以下ステージ定義ファイルの例です。ステージ定義ファイルでは namespace と stages を記述します。namespace 複数のステージ定義ファイルを呼び出した際に名前がかぶらないために付与します。
stages 内は def ブロックをつくりステージを定義してゆきます。以下の例では whomai というステージを定義しています。
|
1 2 3 4 5 6 7 |
namespace: mystages stages: - def: name: whoami command: whoami |
うえのステージ定義ファイルを stages.yml という名前で保存します。パイプライン定義ファイルの方から require ブロックででステージ定義ファイルをインポートします。定義されたステージは call で呼び出します。呼び出すステージは名前空間::ステージ名というフォーマットで記述します。
|
1 2 3 4 5 6 |
require: - stages.yml pipeline: - call: mystages::whomai |
ステージ結果の再利用
これは先に実行ステージ結果を再利用したいという声をもらい作った機能です。三つの特殊変数（__OUT、__ERR、__RESULT）を利用することで先に実行したステージの結果を取得できます。
- __OUT: 標準出力に出力された結果（”true”か”false”）を保持します。
- __ERR: 標準エラー出力に出力された結果を保持します。
- __RESULT: コマンドの戻り値を保持します。
各変数はマップとして利用します。変数のキーとしてステージ名を与えるとステージ結果が得られます。
たとえば以下の例では二つ目のステージが一つ目のステージの出力結果を利用しています。具体的には一つ目のステージで文書のチェックを行い、二つ目のステージで一つ目のステージの標準エラー出力にエラーが出力されたかをチェックしています。二つの目のステージではエラーが出力されてなければ、PDFを作成します。
|
1 2 3 4 5 6 7 |
pipeline: - name: Check document with RedPen command: redpen -c redpen-conf.md document.md -f markdown - name: Convert markdown to PDF command: markdown-pdf -o document.pdf document.md only_if: test -z "`echo __ERR["Check document with RedPen"] | grep ERROR`" |
そのほかの改善点
- Slack への通知をサポートしました
- HipChat のローカル（proprietary）サーバへの通知をサポートしました
- Slack への通知に色がつきました
今後の予定
今後も Walter は開発が継続する予定です。とくにこの冬、Walter はサーバ機能をサポートする予定です。またステージの開始条件を指定できるようにしたいと考えています。現在は前のステージが終了すると即座に次のステージが始まってしまうのですが、開始条件を指定する事で必要なポートの準備が整うまで待つなどの設定を行えるようになります。