ATL 宮下 です。

Walter v2.0.0.beta1 をリリース したので、お知らせします。


Walter とは

Walter とはビルドパイプラインを YAML で定義して実行するシンプルなコマンドラインツールです。

ビルドパイプラインやワークフローを定義して実行するツールは様々ありますが、Walter は徹底定期にシンプル、ということにこだわっています。


v2 の開発動機

v2 は v1 の修正という形ではなく、フルスクラッチで一から開発しています。v2 の開発は次のような狙いで行われています。

  • よりシンプルに使えるようにしたい。
    • そのためには後方互換性も犠牲にする。
  • コードベースをよりシンプルにしたい。
    • 拡張しやすくしたい。
    • 他の開発者がもっと気軽に開発に参加できるようにしたい。

v2 での主な変更点

v2 での主な変更点を説明します。

パイプライン定義フォーマット

v1 では次のように実行するパイプラインを定義します。

同じ内容は v2 では次のように定義します。

buildフェーズとdeployフェーズ

v2 では build と deploy、2つのフェーズにパイプラインを分割できるようになっています。

オプションによって、build だけ実行するのか、deploy だけ実行するのか、build と deploy 両方を実行するのかを指定できます。

外部定義ファイルのフォーマットと呼び出し方

v1 も v2 も、パイプライン定義のファイルを外部に分割して、メインのファイルから呼び出すことができるようになっていますが、そのフォーマットと呼び出し方が変更されています。

v1 では通常の task とは違うフォーマットで外部ファイルによりパイプラインを定義します。

task1.yml

task2.yml

外部ファイル task1.ymltask2.yml は、次のような形で呼び出します。

pipeline.yml

v2 の外部ファイルは次のように、build や deploy といったフェーズ部分を省略して、task のみ記述します。v1 との違いは、namespace を廃し、メインのファイルと同じ形で task を記述できるようにしていることです。

task1.yml

task2.yml

外部ファイル task1.ymltask2.yml は、次のような形で呼び出します。

pipeline.yml

また、外部ファイル単独でも実行できるようになっているので、パイプラインの一部のみ実行してテストすることが容易になっています。

wait_for の書式

ポートのリッスンやファイルの作成などを待ってからタスクを実行する wait_for の書式が変更されています。

v1 では次のようにパラメーターを一行で記述します。

v2 ではパラメーターをYAMLのマッピングで記述します。

通知設定

実行結果の通知先を設定する方法が変更されています。

v1 では次のように通知先の設定を行います。

v2 では次のように、messengernotify に変更され、複数の通知先が設定できるようになっています。

特殊変数の扱い

__OUT, __ERR, __COMBINED, __RESULT といった特殊変数が廃止されています。これらの特殊変数は、__OUT[“task name”] といった形で任意のタスクの標準出力等を別のタスクから再利用するためのものですが、v2 ではパイプラインをシンプルに保つため、ひとつ前のタスクの標準出力のみパイプ経由で受け取る、という形に仕様を変えました。それに伴い、これらの特殊変数を廃止しています。

次のように定義されたパイプラインでは、1番目のタスクの標準出力は、2番目のタスクの標準入力へ暗黙的に渡されています。

GitHub 連携

GitHub からコードを取得したり、プルリクエストと連携したりする機能を削除しました。こういった walter のコアではない機能は、後述する plugin や walter-agent に寄せていく方針です。


ご要望、お気づきの点、プルリクエストなど

v2 に関するご要望、お気づきの点、プルリクエストなどは Walter の GitHub リポジトリ の Issues/Pull requests に登録をお願いします。日本語でも大丈夫です。

v2 は現在βバージョンで、master ブランチではなく v2 ブランチ で開発が進んでいます。v2 へのプルリクエストは v2 ブランチ向けにお願いします。


今後の予定

v1 でも実装していた walter-server と walter-agent は v2 でも実装する予定です。また、通知機能などはプラグインとしてコアから分離したいのですが、これは golang 本体に plugin 機構 が入り安定動作するまで待つ予定です。

Windows も要望があるので対応したいですね。


参考資料

TAGS: