ワークフロー YAML を読む（lint → test → build）

導入

実務でよく見る「lint（書式チェック）→ test（テスト）→ build（ビルド）」の流れを持つワークフローを読み解きます。1行ずつ意味が取れれば、たいていのCI設定は怖くありません。

説明

C# プロジェクトを例にした、現実的な CI ワークフローです。

name: CI

on:
  push:
    branches: [main]          # main への push で動く
  pull_request:               # PR が作られた・更新されたときも動く

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4        # 1. コードを取り出す

      - uses: actions/setup-dotnet@v4    # 2. .NET を使えるようにする
        with:
          dotnet-version: '10.0.x'       #    with: は部品への引数

      - run: dotnet restore              # 3. 依存パッケージを取得
      - run: dotnet format --verify-no-changes   # 4. 書式チェック(lint)
      - run: dotnet build --no-restore   # 5. ビルド
      - run: dotnet test --no-build      # 6. テスト実行

読み方のポイント：

on: のブロック形：レッスン26の on: [push] を詳しく書いた形。「main への push」と「PR」の両方で動きます。PR で動くからこそ、マージ前に自動チェックできます。
with:：直前の uses: で呼んだ部品に渡す引数。ここでは .NET のバージョンを指定。
step は上から順番：どれか1つでも失敗（コマンドが 0 以外の終了コードを返す）した時点で、その job は失敗として止まります。テストが落ちれば dotnet test の行で赤くなります。

flowchart LR
    A["checkout"] --> B["setup-dotnet"]
    B --> C["restore"]
    C --> D["format (lint)"]
    D --> E["build"]
    E --> F["test"]
    F -->|全部成功| G["✓ 緑（マージ可）"]
    D -->|失敗| X["✗ 赤で停止"]

この結果は PR 画面に「チェック」として表示され、緑なら安心してマージ、赤なら原因の step を開いてログを読みます。

まとめ

on: のブロック形で push と pull_request の両方を対象にできる。
with: は uses: した部品への引数。
step は順番に走り、1つでも失敗すれば job が止まる。
結果は PR のチェック表示に出る。