序
アドベントカレンダーの2本目ですが、1本目は時間的に後に出ますw
Vimプラグイン開発
現在、開発といえば、CIでの継続的テストなどは必須に近いところがあります。
ただ、これをVimのプラグイン開発でやるとなかなか大変です
- Vimのスクリプトでテストが難しい(が、まだこれは易しい方)
- Vimという単体で完結するものについて、テスト結果やエラーなどのレポートの連携が難しい
- 他の事例を流用するのが簡単ではない
- そもそも事例があまりなくてわからない(これが一番?)
CI
上記に対して、優秀なVimプラグイン開発者の方々は様々に対応し、それなりに実績を蓄積してきています。
ただ、それでも流用しにくいところはあり、結果としてそこまで広く実施されているとも言えないかもしれません。
今回の例にするのは、vim-jpで開発されている プラグイン支援ライブラリ vim-jp/vital.vim の流儀にそった自分開発ライブラリtsuyoshicho/vital-codec (vital.vim へ contribを目標にしている)のテスト環境についてです。
GitHub Actions
vital-codec のテスト環境ですが、当初は vital.vim の内容を流用させてもらっていました。
それにより
- Travis CI
- vim-themisによるテスト実行マトリクス (LinuxでVim 8.0/8.1/latest、MacでMacVim latest)
- lint系ツール詰め合せによる lintチェック (Linux)
- AppVeyor
- vim-themisによるテスト実行マトリクス (WindowsでVim 8.0/latest)
- Codecov (上記のvim-themisのテスト結果はすべて集計されてカバレッジを明確化)
これ自体はかなりの充実度であり、現時点でできる網羅性としては高いものと言えます。
ただ、その実としていくつか問題がありました。
- lint の結果報告をする reviewdog がそのための token 取得に失敗してテストNGになることがある
- lint 系が1セットなので、なにかでlint自体がNGになると以降が実行されない
- テスト実行が遅い
- reviewdogによるPRへのコメント追加、Codecovへの登録など、いくつかのsecret情報のあつかいの面倒さ
これらの解決とテスト(というかCI的作業項目)の流用性を高めるためにGitHub Actionsでの実行への切り替えにトライしてみました。
結果と内容
結果としてすべて移行できました。
作業方針
まず、作業項目を整理し
- ビルドおよびテストマトリクス
- lint と 例外送出チェック
- ヘルプのタグチェック
へ作業を分解し、それぞれに対応するActionを定義しました。
ビルドとテスト
中身としては、os x vim バージョンの組合せマトリクス、にしたかったのですが実行環境の細かい都合もあり、workflow定義で泥臭く実行処理を作りました。
Linux,Windows,macそれぞれのjobを定義し
- Linuxは8.0/8.1/latestについてビルドしてのテスト実行
- Windowsは8.0/latestをダウンロードしてのテスト実行
- macはMacVim latestをダウンロードしてのテスト実行
と旧来のCIをほぼそのまま移植しています。
ただ、Windowsは処理の都合、PowerShell/Cmdをうまく使ってまわすようにしたりしてます。
また、stepを越えた作業でのデータの引き継ぎできるところにインストールされない場合もあるので...各ツールのインストールのタイミングを変更したりしてます。
そしてCodecovへのレポートはactionで...
処理したかったのですが、結果としてそれはLinuxしか使えなかったので、Windows,macでは手動でやってます。
なおったので全部で利用。
Lintと例外
lint自体は1つのworkflowに定義はしましたが、jobを分割し、個別に並列実行されるようにしました。
中身は、vint、misspell、vimlint、vital-throw-message(例外チェック) です
vint
reviewdogのオフィシャルのactionである
を利用
PRであれば、チェック結果の埋め込みもします
misspell
reviewdogのオフィシャルのactionである
を利用
vimlint
既存の処理方法を流用して、自作でactionを作成
PRであれば、チェック結果の埋め込みもします
vital-throw-message
これはvitalに特有な所があるので、リポジトリ内にactionを作りました。
関連のソースは持ち込みしてます。
チェック
vimのヘルプは検索のためhelptagを生成します、この時にタグ名がかぶるとエラーになります。
このチェック自体はかなり汎用的ですが、reviewdogでの通知とかには向きません。
なので、完全に個別のworkflowとして作成し(別jobなら問題ないんですが、reviewdog使いませんからね)、その成功失敗だけでチェックします。
そのためのactionも作成しています。
結論
結果として、流用しやすい(主観)定義と、codecovのtokenのGitHubでの管理、reviewdogはtoken不要と、流用性が高いものが作れたと思います。