gh-activity-report と NotebookLM で2025年の活動をふりかえる

さて、2025年もあとわずかですね。
今年の GitHub での活動を gh-activity-report と NotebookLM でふりかえります。
この組み合わせでのふりかえりは過去にもブログ投稿をしてますので、詳細はそちらへ
「GitHub Search と NotebookLM で自分の活動を振り返る」

今回は年間のふりかえりなので gh-activity-report と NotebookLM の使い方も若干やり方もアップデートされました。
まず、拡張機能には楽に期間が指定できるように --year オプションと --fy オプションを追加しています。
次に NotebookLM の「レポートを作成」から「ブログ投稿」を今回使ってみました。

出来上がったブログレポートは末尾にコピペしました。（ちょっと長いです）
ちょっと、いや、かなり盛りすぎかなと思いますが、ウソではないかなと思うのでそのまま掲載してます。
まぁ実際に自分のブログにはそのまま使えないですが、観点を得る目的だったらアリかも？と思いました。最近はブログでアウトプットをせず、GitHub で欲しいものを開発してるって感じなので、１リポジトリだけをソースにしてブログ書かせてみるのは、ブログ書くきっかけを作れるかも。

「ブログ投稿」はさておき、自分なりにもふりかえってみます。
NotebookLM の要約の最後のまとめだとこんな感じでした。

まとめとしてはあってるかなと思います。
最近よく使っているプログラミング言語は Go ですね。gh extension を書く場合の定番だからという理由で使い始めたんですが、コーディングエージェントとも相性が良いのかなと最近感じています。エージェントに依頼するとパッケージからドキュメントを読んだり、必要な機能を検索したりして、だいたいのことはやってくれます。自分は C++ で育ってきたのですが、それらだと難しそうだなと感じます。※最近（20以降）の C++ 事情を知らないですが

GitHub Actions のアクション開発を最近はよくやってたんですが、最近のテーマはローカルでも同じことができることとしています。Jenkins のときもジョブに直接書くな、スクリプトは別ファイルにしろと言われて来ましたが、GitHub Actions でも同じだと強く感じています。
GitHub Actions で GitHub に関することを扱うのであれば、gh extension として機能開発をしてアクションとしてはそれを呼び出すだけという構成が個人的な答えだと思っています。
そのへんの話は秋頃に勉強会でお話させてもらったのでよければ参考にしてください。
「gh-extension と aqua で作る GitHub Actions アクション」

開発体験向上としてこのへんに注力しているのは、AI とうまく付き合っていくためとも思っています。
（セキュリティに関しては aqua 任せなんで自分はほとんど何もしてないかな）
AI Ready という考えを意識してたりします。このへんは来年書けたら書きたい。

さて、いよいよ時間がなくなってきましたので、ここらへんでおわりたいと思います。
2025年もありがとうございました。2026年もよろしくお願いします！

---

ある開発者のGitHub年間活動全ログを分析して見えた、生産性を爆発させる5つの習慣

1. 導入：生産性の高い開発者の頭の中とは？

優れた開発者は、一体どのように1年間を過ごしているのでしょうか？その圧倒的なアウトプット、その生産性の源泉は何なのでしょうか？私たちはしばしば完成されたソフトウェアや華々しいリリースに目を奪われがちですが、その裏側にある日々の地道な活動こそが、真の価値を生み出すエンジンなのかもしれません。

本記事では、一人の多作な開発者（srz-zumix氏）の2025年におけるGitHubアクティビティログを徹底的に分析しました。すると、そこからは驚くほど一貫した、そして誰もが参考にできるであろう5つの「習慣」が浮かび上がってきました。

この分析が、あなたの開発プロセスを見つめ直し、改善するための具体的なヒントになることを願っています。さあ、生産性の高い開発者の頭の中を覗いてみましょう。

2. 習慣1：徹底的な自動化—特に自分自身のワークフローを狙い撃て

srz-zumix氏の活動ログを見て、まず目に飛び込んでくるのは、開発ツールや自動化に関連するリポジトリの多さです。これは単なる趣味のツール作りではありません。日々節約される数分が年間では数週間の生産的な時間に変わることを理解した、意識的な「投資判断」なのです。

彼が解決しようとしているのは、自分自身のワークフローに潜む「痛み」です。

• gh-activity-report: 四半期や年次のコントリビューション概要をまとめるという、退屈で手作業になりがちなプロセスを自動化します。
• labeler-action: 新規に作成されたプルリクエストを手動で確認し、タグ付けするというトリアージ作業を不要にします。
• post-run-action: GitHub Actionsのジョブ完了後に行うべき後処理やクリーンアップ作業を自動化します。
• aqua-installer-cache: ツールインストーラーのキャッシュを賢く管理し、CI/CDの実行時間を短縮します。

ここから得られる教訓は明確です。「最も身近な課題、つまり自分自身の非効率な作業を解決するツールを作ることが、結果的に大きな生産性の向上に繋がる」ということです。他人のための壮大なツールを作る前に、まずは自分の足元にある非効率を解消する。その投資は、複利効果で将来の自分に大きなリターンをもたらすのです。

3. 習慣2：再利用可能な「キット」を作り、開発を加速させよ

srz-zumix氏の活動は、単に個別のツールを場当たり的に作っているわけではありません。そこには明確なアーキテクチャ戦略が見て取れます。その戦略の証拠は、go-gh-extensionというリポジトリを中心としたエコシステムにあります。

このリポジトリは、GitHub CLI拡張機能を作成するための共通ライブラリとして機能しており、他の多くのツールがこの基盤の上に構築されています。

• gh-label-kit: ラベル管理ツール
• gh-team-kit: チーム管理ツール
• gh-rule-kit: リポジトリのルールセット管理ツール

これが単なる主張ではなく、体系的な戦略であることは、ログを見れば明らかです。2025年12月初旬の活動は、その見事な証拠を示しています。

1. 12月02日: まず基盤となるgo-gh-extensionに「Guardrails」という機能が追加されます（PR #67）。
2. 12月03日: 翌日、その機能を活用する形でgh-team-kitに「Guardrail」が実装されます（PR #85）。
3. 12月04日: さらにその翌日、gh-rule-kitにも同様の「guardrail」機能が実装されました（PR #17）。

この一連の流れは、共通基盤に加えた一つの改善が、システム全体に効率的に波及していく様子を完璧に示しています。まず汎用的な土台を作り込み、その上に目的に特化した「キット」を組み立てるアプローチは、一貫性の担保、開発速度の向上、メンテナンス性の劇的な改善という、計り知れない利益をもたらします。「車輪の再発明」を避け、再利用可能なコンポーネントを意識的に作る。この「キット化」の発想は、あらゆるプロジェクトに応用できる強力な武器となるでしょう。

4. 習慣3：貢献のループを回せ—エコシステムへの還元が自身を成長させる

srz-zumix氏の活動は、彼自身のプロジェクトだけに留まりません。ログには、著名なオープンソースプロジェクトへの具体的で価値ある貢献が数多く記録されています。

• rhysd/actionlint: 無数の開発者が利用するこの静的解析ツールに対し、パーサーでYAMLのアンカーとエイリアスをサポートする機能を追加しました（PR #568）。
• DeNA/setup-job-workspace-action: ワークスペース設定をより柔軟にするため、repository-nameオプションを追加しました（PR #251）。
• actions/labeler: GitHub公式のラベラーに対し、プルリクエストのレスポンスからブランチ名を取得する機能改善を提案しました（PR #873）。

自分が日々使っているツールを、単なる消費者として利用するだけでなく、改善点を見つけては自らコードを書き、コミュニティに還元していく。しかし、これは単なる利他的な行為ではありません。多くの開発者が利用する外部プロジェクトに貢献することで、自分とは異なる設計思想やコーディングスタイルに触れ、新たな知見を獲得できます。これは、より広い視点を得て自身の技術力を高めるための、極めて効果的な自己投資と言えるでしょう。

ツールを作る→使う→改善して貢献する→新たな知見を得て、また次のツール作りに活かす。

この貢献のループこそが、開発者を継続的に成長させるのです。

5. 習慣4：小さな改善を即座に反映させる、高速なイテレーション

活動ログを時系列で追っていくと、あるリポジトリでの変更が、間髪入れずに別のリポジトリで利用されるという、極めて短いフィードバックループが繰り返し現れます。これは一度きりの偶然ではなく、彼の開発スタイルに組み込まれた意図的なパターンです。

例えば、2025年11月24日の活動を見てみましょう。

1. 16:04: gh-label-kitリポジトリで、バージョンを0.12.0から0.12.1に上げるプルリクエスト（#76）がマージされます。
2. 16:13: そのわずか9分後、labeler-actionリポジトリで、たった今リリースされたばかりのgh-label-kit v0.12.1を利用するためのプルリクエスト（#30）がマージされています。

この「作って、すぐに使う（ドッグフーディング）」という高速なイテレーションは、srz-zumix氏の開発スタイルの核心の一つです。このパターンはログ全体で散見され、例えばgh-label-kit v0.9.0への更新（PR #58）が即座にlabeler-actionで利用される（PR #23）といった例も確認できます。

ライブラリに加えた改善が、実際のアプリケーションでどのように機能するかを即座に検証することで、ツールの品質は急速に向上し、机上の空論ではない、実践的な改善が促されるのです。

6. 習慣5：継続こそが最強の機能である

最後に、そして最も重要な習慣は「継続」です。srz-zumix氏の活動は、年間を通じてほぼ途切れることがありません。その象徴的なコミットが、2025年の大晦日、12月31日に行われています。

• [srz-zumix/gh-activity-report]: 91 - add --year option (2025-12-31T13:23:22Z)

年の瀬も押し迫ったこの日に、自身の活動レポートツールに新しいオプションを追加しているのです。この一つの事実が、彼の開発に対する一貫性と情熱を何よりも雄弁に物語っています。

また、活動内容も派手な新機能開発だけではありません。「Bump version」「update packages」「Fix typo」「Update README.md」といったプルリクエストが数多く見られます。これは、バージョンアップ、パッケージ更新、リファクタリング、ドキュメント修正といった地道なメンテナンス作業が、活動の大部分を占めていることを示しています。

イノベーションは、ある日突然のひらめきから生まれるのではなく、日々の地道な積み重ねと、絶え間ない改善活動の中から生まれる。このログは、開発者にとっての普遍的な真理を改めて教えてくれます。

7. 結論：あなたの次の「自動化」は？

今回、一人の開発者の年間活動ログから、生産性を飛躍させる5つの習慣を抽出しました。これらは独立した習慣ではなく、相互に連携する一つのシステムとして機能しています。

1. 自動化は日々の手間をなくし、深い思考のための時間を捻出します。
2. その時間で、開発を加速させる再利用可能な「キット」を戦略的に構築します。
3. 高速なイテレーションでキットを実戦投入し、即座に品質を向上させます。
4. 得られた知見をエコシステムへの貢献に繋げ、自身を成長させるループを回します。
5. そして、これら全てを支えるのが、日々の地道な継続という最強のエンジンです。

これらの習慣は、決して特別な才能を必要とするものではありません。意識とアプローチ次第で、誰でも今日から取り入れることができるはずです。

さて、この開発者の活動ログから、あなたが次に取り組むべき「自分だけの小さな自動化ツール」のアイデアは浮かびましたか？

---

※ 習慣3：たしかに自分の OSS 以外にもコントリビュートしていますが、マージまでやりきってるのはそこまでないかなと思います。

GitHub Search と NotebookLM で自分の活動を振り返る

GitHub Search で昨日何してたっけ？を簡単に

gh-activity-report という gh 拡張機能をちょうど2年前くらいに作っていました。
こちらは GitHub の検索APIを gh search コマンドをつかって簡単に呼び出し、結果をレポートとして使いやすいように加工して出力する gh 拡張機能です。
gh search 使えばできることなので、わざわざ拡張機能を作る必要もないのですが期間の指定を「XX日前以降」とか「今月」とかがめんどくさかったのでこれを作りました。

例えば、昨日以降に更新した PR および Issue を検索する場合はこのようになります。

gh activity-report -d 1

これを gh search で書くとこのようになります。

gh search issues --include-prs --sort updated --author @me --updated ">=2025-04-21"

今日の日付に合わせて、コマンドを実行する必要があるのでちょっと面倒くさいですよね。
自分は下記コマンドで gh ar -d 1 で呼び出せるようにエイリアス設定をしています。
昨日何してたっけ？先週何してたっけ？と良くなるのでとても便利です。

gh alias set ar activity-report

GitHub Search の結果を定時報告に使う

さて、この gh-activity-report ですが gh search の出力フォーマット以外にも対応しています。gh コマンドをよく使っている人は --jq や --template オプションで出力加工ができることをご存知かと思います。 gh ar でやる場合は -- を使います。

gh ar -d 1 -- --json url --jq ".[].url"

単純な加工であればこれで十分ですが、ちょっと凝った出力にするのはやや面倒です。
--format オプションでいくつかパターンを用意してます。下記は一例です。

gh ar -d 1 --format markdown

gh ar -d 1 --format list

自分用に用意したものなので、お好きなフォーマットにする場合は前述のオプションか、json format で出力して結果をテンプレートエンジンなどで加工するとかもできると思います。
（私は kamidana を使った自作の kamidana-action をよく使っています）
gh の --json オプションは欲しいキーを指定しないといけなく、全部が面倒くさいのですが --format json なら簡単に全部出力できます。

gh ar -d --format json

私はこれらを組み合わせて、週報を自動で書かせています。

定期的なふりかえり

もともとこの拡張機能は活動の報告やふりかえりを目的として作成しましたが、これらは評価のためでもありました。

年に1回や半年に1回のタイミングだとどうしても記憶が曖昧になっていたり、直近の記憶が強くなりがちです。何やってたんだっけ？と毎回なります。
拡張機能で半年間の活動を出力させることもできますが、量がすごく多いのでそれで振り返るのもまた大変です。なので、月ごとにふりかえりをして記録をするという手段を取っています。これを自分リリースノートという名前でやっています。

（個人活動の方でも昔やってましたが、今は止まってます・・・）

自分リリースノートは自身の成長を観点としています。記録にはその観点フィルターを通した要約結果が記載されています。
今回、たまたま別の観点でふりかえりをしたいというきっかけがあり、もう一度 PR などの活動を見返す必要があったので、 NotebookLM に手伝ってもらいました。

NotebookLM で自分の活動をふりかえる

NotebookLM のソースとして gh-activity-report の出力を与えてみましたが、既存のフォーマットでは微妙だったので今回それを目的としたフォーマット（lens-with-body）を追加しています。私がブログを休んでいた期間の情報を出力すると以下のようなオプションになります。

gh ar --since 2023-04-01 -l 1000 --format lens-with-body --visibility public

どのようなフォーマットかというと「repository,number,url,state,title,createdAt,closedAt,updatedAt,author,body

」キーの情報を平文でただただ出力しているだけです。（長いので結果は省略）
既存のフォーマットは GitHub にそのまま書きやすい、人が読みやすいものが多かったのですが、今回のフォーマットは情報をダンプしている感じで人が読みやすいとは言い難いです。

出力した結果をソースとしていれて、どのような活動があったかまとめてもらいました。

なんかいい感じです。
AI の登場で情報をまとめて要約することが手軽になりましたね。

最初は全期間の１ソースだけ用意していたのですが、いまいち認識が甘かったので期間を分割して複数のソースとしました。単純にファイルサイズ（トークン数）というわけでもなさそうで、自分の PR の body がほとんど空っぽだったせいもあるような気もしています。
また、期間中の PR が月ごとに何件あったか調べてもらったら、微妙に一致しなかったりしました。

ちなみに、クセで目的とは関係なく挙動の実験をしてたら、このブログを書くのが２ヶ月遅れましたw　いろいろ調べてみるのは楽しいのですが、現時点での AI に合わせてもしょうもないのでキリにします。

AI 関連の変化は目まぐるしいので、上手に向き合っていけたらいいなと思ってますね。

私は AI 自体に詳しいわけでもなく、利用者としても初心者レベルなので、どちらも触れていって、自分の引き出しを増やせればと思います。

Gemini ではどうか？

Gemini でも同じことができます。
NotebookLM は json ファイルに対応しておらず、平文化する必要がありましたが Gemini だとそのまま json をソースにできるので楽でした。
目的にあわせて使いやすものを使うのが良いんじゃないかなと思います。

最後に

久しぶりブログ書いたけど、感想文みたいになっちゃいましたね。
最近は gh 拡張とか GitHub Actions のアクションを作ってることが多いので、そのへんも紹介できたらいいなと思ってます。では。

【GitHub Actions】Organization/Owner 配下にあるすべてのリポジトリをマトリックスにする

https://github.com/srz-zumix/github-actions-sample/blob/main/.github/workflows/owner_all_repo_matrix.yaml

name: Organization/Owner repo matrix
on:
  pull_request:

permissions:
  contents: read

env:
  GH_TOKEN: ${{ github.token }}

jobs:
  prepare:
    runs-on: ubuntu-latest
    outputs:
      repos: ${{ steps.get-repos.outputs.repos }}
    env:
      TARGET_OWNER: srz-zumix
    steps:
      - id: get-repos
        run: |
            # shellcheck disable=SC2016
            REPOS=$(gh repo list "${TARGET_OWNER}" --json nameWithOwner --template '[ {{ range $i, $e := .}}{{ if ne $i 0 }}, {{ end }}"{{ $e.nameWithOwner }}"{{ end }} ]')
            echo "repos=${REPOS}" >> "${GITHUB_OUTPUT}"
      - run: echo "${{ steps.get-repos.outputs.repos }}"

  main:
    runs-on: ubuntu-latest
    needs: prepare
    strategy:
      matrix:
        repo: "${{ fromJSON(needs.prepare.outputs.repos) }}"
    steps:
      - run: echo ${{ matrix.repo }} 

gh repo list でリポジトリをリストアップして、その結果を --template で json の配列に整形。
fromJSON で matrix にセットします。

gh 使うとこういったことが楽に実現できるので便利です。

今回は以上です。

【GitHub Actions】【reusable workflow / composite action】Enable Debug logging したときだけコンテキストをダンプする step を仕込む

 GitHub Actions の共通アクションやワークフローを書いていると、たまに失敗したときの状態をより詳しく知りたいことがあります。
今回はその一例として github コンテキストなど、GitHub Actions から提供されるコンテキストのデバッグログを仕込みたいと思います。

ところで GitHub Actions の VSCode 拡張が公式からリリースされました。
実はこれを使うとコンテキストやワークフローの候補が出るようになるので、大変便利になりました。
これによって、いちいちこのコンテキストからは何が参照できるんだっけな？と調べる必要が減りました。
※ event の詳細は 2023/4 時点では候補にでなかったので、まだまだ event の詳細は公式ドキュメント（webhook のドキュメントですが同じものが入ります）や実挙動を見て確認する必要がありそうです

ワークフローを書いてる最中はどういう変数があるかはわかりますが、実際にどのような値が入ってくるのかはドキュメントなどから想像するしかありません。
ローカル環境でワークフローを実行する nektos/act のようなツールもありますが、これらは非公式かつ挙動が完全一致するものではないので、実際にワークフローを動かして確認するのが現時点では一番確実です。

私は act の gh 拡張機能（gh-act）を開発しており、その動作確認をこめてコンテキストをダンプしてるので参考にしてみてください。

さて、ワークフローを開発している最中や、リポジトリ専用のワークフローであれば、なにか失敗したときの調査に役立ちますし、常にコンテキストをダンプする step を置いておけば良いかなと思ってます。（実際にそうしてることが多いです）

こんな感じです

    steps:
    - name: $github
      env:
        GITHUB_CONTEXT: ${{ toJson(github) }}
      run: |
        echo "${GITHUB_CONTEXT}"
  

一方、reusable workflow など共通化して多数のリポジトリから使用されるものの場合、機能とは関係のないダンプはいれづらいです。（気にしなくていいとも思ったりもしますが、なんか個人的には避けたかった）

GitHub Actions はワークフローが失敗したときにデバッグログを有効にして re-run できます。理想としてはデバッグログとしてダンプできたらいいなと思っておりました。

reusable workflow 側でデバッグログを有効にされていることをなんらかの方法で判別できればよかったのですが、環境変数やコンテキストでは判別できなさそうでした。
ただ、デバッグログを有効にした場合、最初に紹介した $github ステップの env の設定がダンプされていることに気づきました。

こんな感じ

そしてこの env の評価ですが、 if: false のように常に実行しないステップにしても評価はされました。

先程と同じ用に見えますが、前者は ✔ マークアイコンですが、後者は / マークでスキップされていることがわかります。

ここでようやく結論、タイトル回収です。
「if: false で常に実行しないステップを用意し、知りたい情報を env にセットしておく」
こうすることでデバッグログを有効にしたときだけ github コンテキストの内容を確認できました。この方法は github コンテキストに限らず使えます。


今回は以上です。

【GitHub Actions】コンテキストダンプのススメ

GitHub Actions では github や job などのコンテキストから git の状態や PR の内容、ジョブの情報などが取得できます。
これらを利用してステップの条件をつけたり、処理を変えたりなどができます。
さて、このコンテキストですがどういったものがあるのかは、ドキュメントで確認できます。

コンテキスト - GitHub Docs

ただ、実際にどういった値が入っているかまではわからないですし、ランナーやジョブによって当然値は変化します。
なので、コンテキストをダンプするための repository を用意しておくととても便利です。
私は ci-spec repository でいろいろなイベントトリガーでダンプできるようにしてあります。
https://github.com/srz-zumix/ci-specs/blob/master/.github/workflows/events.yml
この情報って取れるのかな？って探すことが結構あるので重宝してます。

また、github context の json は nektos/act の入力イベントとしても使えるので、常にダンプしておくと便利かもしれません。。かも。。

今回は以上。
act のことは「ブログズミ: nektos/act で GitHub Actions のワークフローをローカル実行」と「GitHub Actions のローカル実行ツール（nektos/act）を便利にする gh extension を作った」で書いたのでよければ見て下さい。

GitHub Actions の Composite Action で post 処理を実現する方法

GitHub Actions での処理の共有方法として action がありますが、現在この action は javascript と docker そして composite の  3  つの方法で作成することができます。
筆者は今から action 作るなら composite をおすすめします。
composite action は登場した当初は runs.steps[*].if や runs.steps[*].uses が使えなかったので、ちょっと力不足でしたが最新のバージョンであればこれらが使えるようになっており、action を作る上で困ることはほとんどなくなったと思います。

じゃあ、タイトルはなんなんだということになりますが、ちょっと凝ったことしようと思うと（他ではできるけど） composite ではできないこともあります。

それがタイトルに書いた post 処理です。
右のスクリーンショットは action に書ける Metadata syntax なのですが、composite だけ post に対応してません。（詳細はリンク先へ）

でも、大丈夫です。というのがこの記事。
いずれ公式で composite action にも post が対応されると思いますが、今の状態でも post 処理できます。

その前に。
post 処理とはどんなものかと言うと、ジョブのステップが全部終わった後に行う処理のことです。みなさんがよく使うであろう actions/checkout でも post 処理が行われています。

こんな感じ。
基本的には action で設定したものをもとに戻したり、docker コンテナを停止したりするのに利用されています。

では本題です。
composite action で post 処理を行うには・・・
「post 処理ができる action を uses で呼び出す」ことで可能です！

つまり、「composite action は uses で他の action を呼び出せるので、javascript/docker action を呼べば良い」のです。

リポジトリが別になっちゃう？
いえ、大丈夫。 uses は相対パスで action を呼び出せます。

つまりこういうことです。

composite action の repository のサブディレクトリに javascript/docker action を配置して、それを composite action から呼び出し、呼び出した action の post 処理を composite action の post 処理の代わりにします。
「uses: "./resources/post-action"」 がその部分で、この action のメイン処理は空で、post 処理で起動したコンテナの終了をしています。

実際にこの書き方をした action のリポジトリはこちら。
https://github.com/srz-zumix/setup-service-jenkins

composite ではない action を使うことになるので、それはそれで問題があったりしますがネストされた action なので実はそのへんもなんとかなっちゃうかもしれないなと思ってます。（javascript action の default node version 問題とか）
（docker action は実行できない os があるので、この目的ではあまりオススメしません）

ざつにざーっと書きましたが、今回は以上となります。では。

GitHub Actions の action 開発者にお願いしたいメジャーバージョンアップするタイミング

 GitHub Actions とっても便利ですね！
個人開発ではもちろんのこと、会社でも便利に使っています。
使うだけではなく action を作ったりもしてます。

さて、本題に入りますが、
会社の GitHub が Enterprise のため github.com の方にはあるが Enterprise にはまだない機能や環境を使われると action が動かないことがあります。
幸い使用する action のバージョンを固定することで回避できるのですが、できることならそのような変更時にはメジャーバージョンアップしてほしいなと思ってます。
（SemVer 採用してる前提ですが）メジャーバージョンでバージョン固定しているケースが多いため、マイナーバージョンアップだと管理下の全リポジトリに対してバージョン固定をして回らないといけなくてすごく面倒くさいのです。。
メジャーバージョンアップならこのような破壊的変更を自然に避けられるので、何卒。
（まぁ Enterprise 使ってないとそういった事情はわからないので仕方がないとは思ってますけど）

実際にあった例としては、

• 「using: "composite"」
  Composite Action が Enterprise でまだ使えなくて動かなくなった。
• 「using: "node16"」
  Enterprise はまだ「docker」か「node12」しか使えない状態だったので動かなくなった。（こっちは Enterprise のアップグレード以外に方法があるなら知りたい）

がありました。
とりあえず using 変えると Breaking Change になるようにするのが良さそうですね。

この辺を自動で対応するなら using の差分があったらラベルつけるとかできればなんとかなりそう。（actions/labeler だとファイル単位なので別のやり方が必要）
なんかいい方法見つけたらブログで書きたいと思います。

以上。

GitHub で草生やさないようにする

 GitHub で「草を生やす」方法はすぐ出てくるのですが、「草を生やさない」方法がすぐに見つからなくて困っていたので備忘録。

というのも、GitHub Actions で定期的に commit をするワークフローがあるのですが、そのコミットが contribution に含まれてしまってました。 
問題の workflow => https://github.com/srz-zumix/wandbox-status/actions（今は修正済み）
このワークフローでは、修正前は自分の GitHub アカウントの noreply メールアドレスを使ってました。

git config --local user.name ${{ github.actor }}
git config --local user.email ${{ github.actor }}@users.noreply.github.com

筆者は noreply ではなく個人のメールアドレスを登録してるのでカウントされないと思ってたのですが、そうではなかったみたいです。
コントリビューションがプロフィールに表示されないのはなぜですか？ - GitHub Docs
※「草が生えない」で困ってる人は↑の公式ドキュメントを読むのをおすすめします。

というわけで、user.email をなんかテキトーなメールアドレスにしたら良いのですが、ちょうど良さげな記事があったのでこれにしました。

「GitHub Actionsのボットがコミットしたようにアイコンをつけるにはメールに「github-actions[bot]@users.noreply.github.com」を指定すれば良い - nwtgck / Ryo Ota」

git config --local user.name github-actions[bot]
git config --local user.email github-actions[bot]@users.noreply.github.com

これで無事、定期ジョブの自動コミットで草を生やさないようにできました。
（濃い草が自動コミットも含まれていた時期）

めでたしめでたし。

GitHub Actions Composite Action で uses が使えるようになった！

GitHub Actions: Reduce duplication with action composition | GitHub Changelog

GitHub Actions では Composite Action でワークフローの一部を１つのアクションとしてまとめ共有できることができます。
複合実行ステップ アクションの作成 - GitHub Docs

GitHub Actions は YAML のアンカー・エイリアスに対応しておらず、 Azure Pipelines のような Templates 機能もありませんが、この機能で Action に切り出すことで似たようなことができます。
Composite Action は Docker や Javascript Action と違い、通常のワークフローの記述と近いかたちで書くことができますので、よりアンカー・エイリアスや Templates と近い感覚で記述ができます。

**近い**としたのは Composite Action で書けることは通常のワークフローよりも制限がされているからです。
uses もその１つでした。
今回のアップデートで uses が使えるようになり、checkout アクションや python / node / ruby などの setup 系アクションを含んだ Composite Action を書けるようになったので、かなり便利になりました！

（個人的には shell を動的に解決したいとか conditional (if) を使いたいとかはありますが、uses が対応されたことで大分使い勝手が良くなったので嬉しい）

GitHub Actions のコンテナに setup-python したときの error while loading shared libraries 対応

python: error while loading shared libraries: libpython3.8.so.1.0: cannot open shared object file: No such file or directory

GitHub Actions で setup-python 使って python のテストをしていたのですが、とあるときから上記エラーが出るようになっていたので、以下の修正で対応しました。

修正前

 
zapcc-basic-test:
    runs-on: ubuntu-18.04
    container: docker://srzzumix/zapcc
    needs: prepare
    steps:
    - uses: actions/checkout@master
    - uses: actions/setup-python@v2
      with:
        python-version: 3.8
    - name: zapcc test
      run: |
        make -C test clean
        make -C test showcxxversion
        make -C test check_stdlib
        make -C test -j1 IUTEST_REQUIRE_PYTHON=1
        make -C test test

修正後

zapcc-basic-test:
    runs-on: ubuntu-18.04
    container: docker://srzzumix/zapcc
    needs: prepare
    steps:
    - uses: actions/checkout@master
    - uses: actions/setup-python@v2
      with:
        python-version: 3.8
   #### ここを追加 ####
    - name: Set Python environment variable
      run: echo "LD_LIBRARY_PATH=${{ env.pythonLocation }}/lib" >> $GITHUB_ENV
   ################
    - name: zapcc test
      run: |
        make -C test clean
        make -C test showcxxversion
        make -C test check_stdlib
        make -C test -j1 IUTEST_REQUIRE_PYTHON=1
        make -C test test

setup-python が pythonLocation 環境変数をセットしてくれるのでそれを使って LD_LIBRARY_PATH を設定します。

以上。

2020/10/6 追記

set-env コマンドは Deprecated だったので修正しました。
GitHub Actions: Deprecating set-env and add-path commands - GitHub Changelog

修正前： echo '::set-env name=LD_LIBRARY_PATH::${{ env.pythonLocation }}/lib'
修正後： echo "LD_LIBRARY_PATH=${{ env.pythonLocation }}/lib" >> $GITHUB_ENV

GitHub Sponsor のバッジを付ける方法

GitHub でプロフィールリポジトリを作ることで自由にカスタマイズできるようになったので、GitHub Sponsor のバッジを付けてみました。
https://github.com/srz-zumix

https://github.com/badges/shields/issues/4683

バッジは Shileds.io を使って生成してます。

やり方は↑こちらにありました。

https://img.shields.io/static/v1?label=Sponsor&message=%E2%9D%A4&logo=GitHub&color=ff69b4&link=https://github.com/sponsors/srz-zumix

Markdown の場合は以下のようになります。

ユーザー名を自身の名前に変えて使ってください。

[![GitHub Sponsor](https://img.shields.io/static/v1?label=Sponsor&message=%E2%9D%A4&logo=GitHub&color=ff69b4)](https://github.com/sponsors/srz-zumix)

[Doxygen] @page の名前には小文字を使おう

Doxygen の page コマンドの説明によると 「ページへの参照となる <名前> には、 すべて小文字 (mypage1 など) を使用するべきです」とあります。

iutest のドキュメントは GitHub Pages で公開しているのですが、この注意点を知らず 

/**
 * @page    CMDLINE     コマンドラインオプション
 * @par     Command Line Options

のように大文字を使っていました。

ただ、大文字でも特に問題なくドキュメントの生成はできますし、特に問題なく使えていると思っていました。

しかし、実は問題があったのでこの記事を書いているわけです。

名前を大文字にした場合のファイル名が問題だった

@page の名前を大文字にすると、アンダーバー(_) + 小文字に変換されて html ファイルが出力されます。

そして GitHub Pages ではデフォルトで jekyll が有効になっており、アンダーバー(_) で始まるファイルが URL 指定で直接開けず 404 になってしまっていました。。。

対処方法

アンダーバー(_)始まりのファイル名を修正する

Doxyfile の設定で CASE_SENSE_NAMES を YES にすると、文字の変換をせずそのままの名前で出力されるようです。

ただし、大文字小文字を区別しないファイルシステムでは問題になる場合があるので、ドキュメントが推奨するように全部小文字にするのが良さそうです。

GitHub Pages の jekyll を Disable にする

jekyll を無効にすればアンダーバー(_)始まりのファイルでも開けるようになります。

方法はこちらを参考にしてください。 GitHub ioでjekyllをdisableにする - adragoonaの日記

「.nojekyll」ファイルをルートに commit すれば ok です。

結果

今回は前者の方法で対応しました。

ちゃんとアクセスできるようになりましたね。

[iutest] ドキュメントの置き場を GitHub Pages に集約した

issue いただきまして iutest のドキュメントの構成を変更しました。

（issue ありがとうございますmm）

これが、

こうなりました。

ドキュメントを GitHub Pages へ

まず OSDN においていた最新バージョンのドキュメントを GitHub Pages に引っ越ししました。

こちらのドキュメントは実は2年くらい更新をし忘れていました。。。

そこでドキュメントの更新は GitHub Actions でタグが作られたら自動で更新されるようにしました。

次にもともと GitHub Pages においていた master ブランチ HEAD バージョンのドキュメントですが、こちらはトップディレクトリから master ディレクトリに移動しました。ディレクトリ構成は以下のとおりです。

最新バージョンのドキュメントは latest ディレクトリに push されます。

OSDN からリダイレクト

続いてもともと OSDN にアップロードしていたドキュメントページにアクセスしたら、GitHub Pages にリダイレクトするように設定します。

まずはサーバーへのアクセスをします。（これまでもやってるはずですが、いつも忘れてしまうのでメモ）

OSDN のドキュメントはシェルサーバーの「/home/groups/<プロジェクトUNIX名の1文字目>/<プロジェクトUNIX名の1、2文字目>/<プロジェクトUNIX名>/」にあります。iutest の場合は「/home/groups/i/iu/iutest」です。サーバーには鍵を登録してアクセスします。

OSDN では .htaccess でリダイレクトの設定ができるので、OSDN ドキュメントのサンプルを参考に設定しました。

RewriteEngine on
RewriteBase /doc
RewriteRule ^(.*) https://srz-zumix.github.io/iutest/latest/$1 [R=301,L]

最後に

手動更新は早急にやめたほうがいいですね。

では。

[GitHub Actions] Actions の PR 時に自分自身をアクションとして実行する

GitHub Actions を使う側（ユーザー側）は通常 @v1 や @master などリリースタグ（またはブランチ）を指定して使いますが、GitHub Actions を作っている側（開発側）としては PR ブランチ側の変更で Action を実行してほしくなります。

もちろん、PR ブランチの名前を @ で指定すればそのブランチで Action が実行されますが、それではそのままマージできませんし、PR のたびに名前を変えるのも手間です。

以下は「ブログズミ: [技術書] 画像のフォーマットチェックを GitHub Actions でしてみた」で紹介した画像ファイルチェック Action を例にしています。

name: GitHub Actions
on:
  pull_request:

jobs:
  all-ok:
    runs-on: ubuntu-latest
    steps:
    - name: clone
      uses: actions/checkout@master
    - uses: srz-zumix/actions-book-image-check@master
      with:
        path: ./test/format
        formats: "JPEG, PNG"

上記は普通に使用する場合の例になります。

では本題である PR 自身のアクションを実行する方法ですが、

GitHub Actions はリポジトリ内のパス指定でも実行可能なので、「./」を指定すれば OK です。

PR で実行されるワークフローを用意して「./」で Action 実行しておくと良いと思います。

name: GitHub Actions
on:
  pull_request:

jobs:
  all-ok:
    runs-on: ubuntu-latest
    steps:
    - name: clone
      uses: actions/checkout@master
    - uses: ./
      with:
        path: ./test/format
        formats: "JPEG, PNG"

今回は以上です。

では。

GitHub Actions で [ci skip] できるようにしました

[ci skip] とは

多くの CI サービスで採用されている、コミットメッセージでビルドスキップができるコマンドです。
ドキュメントのみの更新とかでわざわざビルドしなくてもいい場合に便利な機能です。

GitHub Actions における ci skip

GitHub Actions は Azure Pipelines から派生しているので
「***NO_CI***」が使sえるかな？と思っていましたが、それはない模様。

* Build pipeline triggers - Azure Pipelines | Microsoft Docs
* GitHub Actions ***NO_CI*** alternative - Stack Overflow

Azure Pipelines ベースなので、一般的な 「[ci skip]」 も使えません。
つまり、GitHub Actions では現状 CI をコミットコメントからスキップすることができません。


・・・とはいえ、スキップしたい！ということで今ある機能でなんとかできないかやってみました。

Workaround

steps.if でなんとかしてみた

steps.if は条件付きでステップを実行するかしないかを制御する機能です。
これがあったので、以下のようにすることで、「ステップ」のスキップは実現できていました。

steps:
    - name: Check condition
      if: "! contains(github.event.head_commit.message, '[ci skip]')"

上記の方法で、最新コミットのコミットメッセージに「[ci skip]」が含まれていたら、そのステップをスキップすることができます。
ただ、これはあくまでステップのスキップなので、他サービスの [ci skip] とはだいぶ異なります。。

job.if がキターー

GitHub Actions - new workflow syntax features - The GitHub Blog
job 単位での制御がしたい！と思っていたら来ました！！

jobs:
  build:
    runs-on: ubuntu-latest
    if: "! contains(github.event.head_commit.message, '[ci skip]')"

steps.if のときと書き方は同じで、job のところに書けるようになりました。
これで job のスキップができるようになりました。

受け入れジョブを作ってそこを起点にする

さらに他 CI サービスでの挙動に近づけるために、依存関係を作成します。
[ci skip] をチェックするジョブを起点にジョブをぶら下げることで、スキップしたジョブの後続もスキップするようにします。

jobs:
  prepare:
    runs-on: ubuntu-latest
    if: "! contains(github.event.head_commit.message, '[ci skip]')"
    steps:
      - run: echo "${{ github.event.head_commit.message }}"

  build:
    runs-on: ubuntu-latest
    needs: prepare

prepare ジョブがスキップすると build ジョブもスキップします。
これで完成です。

スキップ結果

スキップすると以下のように表示されます。


checks にはのらないようです。（CI サービスによっては出たりする）

まとめ

ci-skip/WORKAROUND.md at master · srz-zumix/ci-skip
いろいろ説明を省きましたが、こちらで今回の方法をまとめいます。

今回のポイントは github context の使い方かな、と思います。
公式ドキュメントの github context では省かれていますが、ドキュメントの表以外にも取得可能な情報がたくさんあります。
今回は 'github.event.head_commit.message' でコミットメッセージを取得しました。

↑のまとめに github context から取得できる値の例と、ダンプ方法も書いてあるので参考にしてください。

最後に

私が使っている CI サービスでの [ci skip] 機能に関して、まとめているリポジトリがありますので
他のサービスでの [ci skip] を確認する場合、よろしければこちらも参考にしてください。

https://github.com/srz-zumix/ci-skip


では。

[Codefresh] PR comment に特定の文字列があったらトリガーする

Codefresh の Free Plan では1ヶ月のビルド数制限があるため、すべてのブランチや PR に対してテストを実行しないようにしています。
が、たまにこの PR でも Codefresh のテスト回したいなーというケースがあったので、PR の comment に反応してテストが実行されるようにしてみました。

(※ Codefresh の Free Plan はちょっとよくわかってないことがあるので、ビルド数制限なにそれ？な場合もあるかも。詳細：「ブログズミ: [Codefresh] Free Plan の内容がよくわからない・・」)

設定の仕方

まず、プロジェクトのパイプライン設定を開きます。
右側に「TRIGGERS」のタブがあるのでそれを開きます。


「ADD TRIGGER」を2回押します。


「GIT」を選択して、次へ。


「TRIGGER BY」は「Pull request comment added」のみを選択。


「PR COMMENT(REGEX EXPRESSION)」に特定の文字列を識別する正規表現を入力します。
今回は「run codefresh」がコメントに含まれていたら、TRIGGER されるようにしてみました。

設定は以上です。

キックしてみる

PR に「run codefresh」とコメントすると、ビルドが始まります。（CI 失敗してるのは気にしないでください）
テストリポジトリはいつもの iutest です。

まとめ

フリープランで CI を使わせていただていると、ビルド制限で困ることが多いです。
ブランチフィルターなどで実行数を減らすことができますが、逆に、フィルターアウトされるブランチでもテストを実行したいケースがでてきます。

そのようなケースに備えて、コメントトリガーに対応しておくと CI Life がより快適になります。
今回は Codefresh で行いましたが、他の（コメントトリガーできる）CI でも随時対応していきたいと思います。

では。

[GitHub Actions] 公式 Badge を付ける

旧 GitHub Actions ではバッジがなくて、以下を利用させて頂いていたのですが、
CultureHQ/github-actions-badge: A GitHub Actions README badge

最近バッジ表示できないなーと思っていて、リポジトリを覗きに行ったら
公式のバッジが取得できることを知りました！

（ドキュメントはまだないっぽい）

Markdown だとこうなります。

[](https://github.com/{owner}/{repo}/actions)

「ブログズミ: 新しい GitHub Actions に移行しました」
先日の記事でバッジ早くくれ！と言ってましたが、もうありました！！
お詫びして訂正いたしますm(__)m

やったぜ！


※ブランチ指定はまだできない？検証中

新しい GitHub Actions に移行しました

GitHub Actions now supports CI/CD, free for public repositories


新しい GitHub Actions が使えるようになっていたので、
iutest のワークフローを 旧 GitHub Actions から移行しました。
migrate github actions by srz-zumix · Pull Request #274 · srz-zumix/iutest

HCL な main.workflow から YAML への変換

以前の GitHub Actions は HCL というフォーマットを採用していましたが、新しい GitHub Actions は他の CI サービスと同様に YAML での configuration になりました。
HCL だとどう書くんだろ？といちいち調べる手間が減るので地味に嬉しい変更です。
ただここで、HCL で書かれた workflow を YAML に直す手間が必要になるのですが・・・



さすが GitHub 、ちゃんと Migration tool を用意してくれていました！
Migrating GitHub Actions from HCL syntax to YAML syntax - GitHub Help

手順は至って簡単で、
ツールをダウンロード・展開したら、目的のリポジトリ下でツールを実行するだけです。
（ブランチ切り替えとかも含めて丁寧に説明されていますので、手順は上のリンクから確認してください）

手順どおりに行えば一瞬で移行が完了します。

自動変換後に調整したこと

ジョブを分けた

以前の GitHub Actions ではアクションごとにステータスがついていたのですが、新しい GitHub Actions でジョブごとにステータスがつくようでした。
変換した YAML ではアクションがすべて 1つのジョブにまとめられていたので、前と同じステータス通知になるようにジョブを分けました。
https://github.com/srz-zumix/iutest/pull/274/commits/b9cbdc04b6620c210e03c10085ec949092e94e9d

チェックアウト

ジョブを分けたら、それぞれにチェックアウトステップが必要でした。
各ジョブの steps に 「uses: actions/checkout@master」を追加しましょう。

steps:
    - uses: actions/checkout@master

通知設定の変更

新しい GitHub Actions になったからなのか、いつぞやからかメールで通知が来るようになっていたので無効化しました。
https://github.com/settings/notifications を開くと「GitHub Actions」の項目があるのでそちらで設定します。


「Web」にすると、GitHub の右上のベルマークのところに通知が飛ぶようになります。

変わったこと

新しい GitHub Actions に変わって大きく変わったのは
* YAML になったこと
* Windows / Mac OS が使えるようになったこと
でしょうか。

Windows や Mac OS でのテストは現在は他の CI サービスを使っているので、近々で試すことはないかもしれませんが、これらをサポートする CI サービスもだいぶ増えた印象です。
各 CI サービスがどの OS を使えるか、以下のリポジトリで個人的にまとめているので興味がある方はどうぞ。（PR お待ちしてます）
https://github.com/srz-zumix/ci-specs/blob/master/README.md#build-environment

最後に

2019/8/23 追記

ドキュメントにはまだ書かれてないようですが、すでにバッジをつけることはできてましたmm
「ブログズミ: [GitHub Actions] 公式 Badge を付ける」

早くバッジください

[GitHub] Squash and merge したブランチを自動でまとめて消す

PR を普通にマージしたときは、merged なブランチを列挙して branch -d すればよかったのですが、
（こんな感じ： git branch --merged | grep -v \\* | grep / | xargs -I % git branch -d %）
「Squash and merge」すると、実際にブランチをマージしているわけではないので、branch --merged に列挙されず、上記方法でお掃除できずに困ってました。

結構、ローカルブランチが溜まってきたのでお掃除したいなーと思い、調べてみたらドンピシャな記事がありました。
GitHub で Squash merge されたブランチを削除する · ryym.log

詳しいことは、こちらの記事を読んでいただければと思います。


で、これで終わると、この記事自体の内容がないよう、となってしまうので、自分好みにカスタムした alias をおいておきます。

del-squashed-branch = "!f(){ base_branch=${1:-master} && echo ${base_branch} && git checkout -q ${base_branch} && git for-each-ref refs/heads/ "--format=%(refname:short)" | while read branch; do mergeBase=$(git merge-base origin/${base_branch} $branch) && [[ $(git cherry origin/${base_branch} $(git commit-tree $(git rev-parse $branch^{tree}) -p $mergeBase -m _)) == "-"* ]] && git branch -D $branch; done; git checkout -q -;};f"
  del-sq = !git del-squashed-branch `git def-branch`
  def-branch = !git ls-remote --symref origin HEAD | head -n 1 | cut -f 1 | cut -d "/" -f 3-

もとの shell command だと master との比較になってましたが、他のブランチを指定できるようにしました。
iutest の開発中は develop に PR 出して、ある程度安定したら master にマージするようにしているので、
develop ブランチを指定して、お掃除したかったのでこうしました。

また、短いエイリアスの方はデフォルトブランチを指定するようにしました。
（これは仕事のときに使うことを想定してこうした）

今回は以上です。

追記

git symbolic-ref --short refs/remotes/origin/HEAD | cut -d "/" -f 2

では正しく GitHub のデフォルトブランチを取得できてませんでした。

git ls-remote --symref origin HEAD | head -n 1 | cut -f 1 | cut -d "/" -f 3-

に修正しました。

EditorConfig の設定に従っているかをテストしてみた

どうも、先日 .editorconfig の記述に typo をずっと放置していて驚愕した僕です。
ブログズミ: .editorconfig ファイル自体の Lint を CI で回す

.editorconfig "自体"の Lint ができたので、今回は .editorconfig に従っているかチェックしたいと思います。

こんな方にオススメ

.editorconfig を開発途中から導入した場合

iutest もそうですが、仕事のプロジェクトでも最初から .editorconfig が用意されているケースがなく、あとから .editorconfig を追加するケースをよく目にしています。
.editorconfig を導入したあとは、対応しているエディタで作業していれば、.editorconfig に従っていない記述が混入することはないはずですが、開発途中に導入された場合は変更が加わらない限り補完されません。

従ってないことでクリティカルな問題が出ることは少ないと思いますが、作業者が変更したところ以外に差分が出るとレビューの際にじゃまになったりするので、やる意味はあるかなと思います。

.editorconfig に対応していないエディタからのコミッターがいる

このケースは存在するのだろうか？という疑問は置いておいて…
git の pre-commit とかに仕込んでおくと、対応している人と対応してない人が無駄に差分を出し合うことがなくなるかなーと思います。

使った Lint ツール

今回の検証では、2 つの Lint ツールを使いました。
使ってみた結果、一長一短あったため 2 つとも採用しています。

Editorconfig Checker

最初に見つけたツールが、Editorconfig Checker です。
https://github.com/editorconfig-checker
複数の言語に対応しているようで、JavaScript/Go/PHP/Java のリポジトリがありました。
今回は最初に見つけたのが npm package だったのでそちらを使うことにしました。

eclint

もう１つは eclint です。
https://github.com/jedmao/eclint
こちらも npm package があり、Editorconfig checker を npm で取ってきたこともあり、すぐに使えそうだったので試してみました。

Editorconfig Checker の使い方と注意

npm install などセットアップについては省略します。

使い方は単純で、解析したいパスを渡すだけです。
オプションで除外パスの指定もできるので、エディタで編集しないようなファイルを除外しつつチェックができます。
また、デフォルトで .git ディレクトリ以下や画像ファイルの拡張子は除外してくれるのと、--dotfiles or -d オプションで dotfiles を除外できるので、単純にルートディレクトリを解析するでも問題ないかもしれません。

以下は、iutest でのオプションの抜粋です。
Visual Studio のソリューション・プロジェクトファイルだけ除外しました。
CI サービス上で実行する想定なので、git 管理外のファイル除外には対応してません。

"scripts": {
    "eccheck": "editorconfig-checker --exclude-regexp \"\\.sln|\\..*proj\" ."
  },

これで npm run eccheck を実行すれば検証してくれます。
このような形でレポートされます。

注意点

Editorconfig Checker は、文字コード（charset）の検出ができないです。
BOM のつけ忘れを検出したいなーと思ったのですが、これができなかったのがもう１つツールを使うことにした理由です。

eclint の使い方と注意

続いて eclint です。
こちらも npm install などのセットアップについては省略します。
eclint も基本的には検証したいパスを引数に渡すだけで使用できます。
Editorconfig Checker とは違い除外オプションはないので、ワイルドカードでの指定や、find コマンドなどを使ってファイルのリストを渡すなどの工夫が必要です。

以下は、iutest でのオプションの抜粋です。

"scripts": {
    "eclint": "npm-run-all eclint:*",
    "eclint:src": "eclint check ./src",
    "eclint:include": "find ./include -type f -not -name iutest_ver.hpp | xargs eclint check -s 2",
    "eclint:root": "find . -maxdepth 1 -type f | xargs eclint check"
  },

これで npm run eclint を実行すれば検証されます。
（除外指定をしつつワンライナーで書くのが手間だったので npm-run-all を使いました）
このような形でレポートされます。


Editorconfig Checker ではできなかった charset の検出ができました。

注意点

さて、charset の検出はできましたが、いいことだけではありません。
eclint はインデント判定もちゃんとしてくれるのですが、これがちょっとノイズになってしまいました。
「インデント」ではなく「整列」のために空白を入れたものまで警告されるためです。

具体的には以下のようなコードです。

enum Level
    {
          LOG_INFO
        , LOG_WARNING
        , LOG_ERROR
        , LOG_FATAL
        , LOG_LEVEL_NUM
    };

私は列挙や関数引数を改行して書く場合、「,」を行末ではなく行頭に書くようにしています。
そして、視認性の観点から最初の「,」のいらない要素に関しては、名前の先頭が揃うように空白を挿入しています。

これがインデント幅 4 の設定に適合せず警告されるのです。
個人的に、これは許容したいため 「-s 2」 オプションをつけて、インデント幅 2 として検証をしています。

また、コメント中の整形であれば以下の設定（もしくはオプション指定）で無視することができます。


ただ、それでも無視しきれないケースがあったため、iutest_ver.hpp だけ検証対象から除外しています。
（Editorconfig Checker は幸か不幸か、インデントの検証がされないようなので iutest_ver.hpp は Editorconfig Checker で検証するって感じです）

おまけ： GitHub Actions

GitHub Actions の使い方が少しわかってきたので、こちらの検証は GitHub Actions で行うようにしました。今回は、特に自分ではアクションを作らず、既存の npm アクションを使ってます。

action "lint:editorconfig" {
  uses = "actions/npm@master"
  args = ["apt-get update && apt-get install -y git && npm install && npm run lint:editorconfig"]
  runs = "bash -c"
}

最初に git をインストールしているのは npm アクションのコンテナに git がインストールされていないため、git 依存のあるパッケージを取ってこれないためです。
npm の ENTRYPOINT は npm コマンドになっているので、runs に bash を指定して install から npm run までするようにしました。
この点だけ手間取りましたが、あとは簡単に組めました。

まとめ

なんで人間がコーディング規約チェックすんねん

— Z.Z.ずみっくす (@srz_zumix) 2016年9月5日

機械的にチェックできないものをコーディング規約にすべきじゃないのでは？

— Z.Z.ずみっくす (@srz_zumix) 2016年9月5日

自動化しましょう！