editorconfigが反映されてるかチェックするGitHub Actionを作りたい

こーのいけ

前提

EditorConfig のメーリングリストに投稿があった。
「2024年のCI Lintの始め方」みたいな感じで

eclint が良く紹介されてるけど何年も更新されてないし、アーカイブされてる
eclint Go版もあるけど Ver 0.5.0 だしイマイチ安定してないよね
editorconfig-checker が新しいし安定してるしこれが良いっぽい？
- （筆者追記）なんか GitHub Actions 対応に消極的な感じ
Mega-Linter の使用が示唆されてるけど Docker イメージ 10GB だしちょっとね

という話

こーのいけ

それを受けて

個人的には EditorConfig はかなり好きで GitBucket にも EditorConfig 対応を追加する PR を書いたりしたこともある。

あらゆるリポジトリで設定すべきだと思っているが、使用を強制する Lint の仕組みがないのがイマイチだった。前にも同じように eclint や editorconfig-checker を調べてイマイチで結局諦めていた。

そういうことなら作っちゃおうか！と意を決したので色々と調査結果をまとめる上でまずはこのスクラップにまとめていく。

こーのいけ

技術要素

.editorconfig のルール取得

あるファイルに対してどういう設定がされているか取得する必要がある。これは EditorConfig の Core ライブラリを使うと簡単に取得できる。公式サイトによると

C
Java
Python
JavaScript
Lua
.NET
Ruby
Go

のライブラリがある。検索したところ Rust のクレートもあったが7年も更新されていない

ファイルのテキスト／バイナリ判定

EditorConfig の場合、バイナリファイルに対して [*] のルールを適用しちゃマズいので対象ファイルの判定ロジックが必要なはず。
時期を同じくして Google がファイル内容判定ツールの google/magika をリリースした。
magika の判定結果で text か code なものだけ対象にすれば良さそう。

ちなみに editorconfig-checker では gabriel-vasile/mimetype が使われている

文字コード判定

editorconfig の設定はインデント関係・改行関係・文字コード設定がある。
このうちの文字コード設定のチェックにいわゆる chardet 系のライブラリがあると良さそう。

こーのいけ

実装言語

magika は Python ライブラリなので Python が良いのか、という感じもあるけれど、文字列処理をガシガシやるので実行速度に懸念がある。
magika を外部コマンドとして起動して結果を jsonl で出してパースすれば良さそう。

それを踏まえると Go か Rust か Zig かなというところ。Zig は editorconfig Core Library も chardet も無くてつらそうだなということで除外。

Go

editorconfig core library がある
saintfish/chardet（12年前）か gogs/chardet（3年前）

Rust

editorconfig core library がない（FFI でいいかな・・・？）
thuleqaid/rust-chardet（7年前） hsivonen/chardetng（3年前）とかもあるが、nickspring/charset-normalizer-rs（3か月前）があって良さそう

結論

何となく Rust 書いてみたいし Rust にしてみよう

こーのいけ

やりたいこと

DevContainer

開発環境は magika 入れたりもする関係で docker に閉じ込めたいので、DevContainer を採用したい。

https://containers.dev/guide/dependabot 見てたら devcontainer-lock.json とか CLI とか書いてあって自分の知ってる DevContainer と違う・・・状態になってるので知識のアップデートもしなきゃ。

GitHub Action 化

コマンドラインでも出来れば使えるようにしておきたいけど、メイン目標はあくまでも GitHub Actions での実行ということにしておく。
https://docs.github.com/ja/actions/creating-actions/creating-a-docker-container-action あたりを見ていく感じかな。
CI として結果を表示させるための出力形式はどうだっけ・・・後で調べる

ghcr

Docker action として実装することになるけど、あれって確か docker build が CI 時に走るんじゃなかったっけか。中で Rust のビルドまで回したくないからベースイメージを ghcr に上げておくと良さそう？

バイナリリリース

やるかどうか未定。

dependabot

まあ入れるよね
👆に書いたように devcontainer.json も対応してるみたいで面白い

tagpr

普段は release-drafter を使うことが多いけど、今回は Songmu/tagpr を使ってみようと思う。
Actions だと v1.2.3 とかをリリースしたときに v1 タグの向き先変えたりしなきゃならないんで haya14busa/action-update-semver も使う必要がある。

あ、でも PR のカテゴリ分け機能が tagpr にはないのか・・・やっぱ release-drafter にしようかな

tagpr で行く場合は Autolabeler 機能もないので actions/labeler あたり入れるか

pr-size-labeler

そんなに重要な情報じゃないけど、なんとなく面白いので CodelyTV/pr-size-labeler も入れてみよう。
そういえば正規表現マッチの実装間違いがあるんで PR 出してたんだけど放置されてるな・・・

PR-Agent

業務で使って割と面白かった Codium-ai/pr-agent も入れてみようかな。
OpenAI の API 使うから色々丁寧に設定しないといけない気がする。

actionlint

rhysd/actionlint も入れよう。

editorconfig の lint

ドッグフーディング大事

Rust の fmt/lint 関連

これは要調査

ベンチマーク

パフォーマンス気になるツールな以上、ベンチマークは入れたい。同じようにパフォーマンスを気にする Rust CLI ツールの Biome が benchmark ディレクトリとか Dockerfile.benchmark とか benchmark.yml ワークフローとかあるんで詳しく見てみると良さそう。

パッと見たら codspeed.io を使ってる様子。Free for open-source projects ってあるしお世話になろうかな。