jmapc の開発

jmapc 自体の作業は、ほとんどが2つのコマンドで足ります。 1つはテストを走らせ、もう1つはカタログから生成されるものを作り直します。 CI が最初に実行するのもこの2つです。

go test ./...        # エンドツーエンドのテストを含むすべて
go generate ./...    # ランタイムの型と、全言語のサンプルクライアントを再生成する

サンプルは言語ごとに3度生成され、example/client、example/rust/src/jmap_client、example/ts に出力されます。 残る2つがコンパイルできるかどうかは Go のテストでは分からないので、CI は Rust に cargo fmt --check と cargo test を、TypeScript に tsc --strict を実行します。 どちらにも生成コードと並ぶ手書きの検査があり、スタブを相手にランタイムを動かします。 ヘッダが送られること、認証がそれに優先すること、セッションがキャッシュされること、そして 200 を返しながら拒否を含む /set がやはりエラーになることを確かめます。

スキーマも同じやり方で、同じ理由から検証します。 バリデータが example のリクエストを受け入れ、スキーマが捕まえると主張する間違いを拒むかどうかは、Go のテストには言えません。 example/schema/check.mjs が、その時点のカタログから書き出したスキーマに対してバリデータを実行します。

ここでジェネレータをソースから実行しているのは、このリポジトリがジェネレータの居場所だからです。

ランタイムの型とサンプルのクライアントはコミットされていて、それらをカタログが今生成する結果と比較するテストがあります。 データモデルを変えたのに再生成し忘れると、見逃されるのではなくビルドが失敗します。 CI では同じ検証に加えて、gofmt、go vet、govulncheck を実行します。

リリースは、変更が main に入ったあとにタグを push して作ります。 リリースノートは CHANGELOG.md  のそのタグの節で、何が変わったかを、利用側にとっての意味でグループ分けし、破壊的変更を先頭に置いて書きます。 節はタグより先に書いてください。 対応する節がないタグはリリースを失敗させます。空の本文で公開するよりよいからです。

各項目は、どれだけ長くなっても1行で書きます。 GitHub はリリース本文を、渡された改行のまま表示します。 80 桁で折り返した段落は、リリースページでも 80 桁で改行された段落になります。