GitHub Actions

What You Will Learn What GitHub Agentic Workflows are How they differ from traditional GitHub Actions Benefits for Claude Code users What can be automated in a 200K-line SaaS project Key factors in the adoption decision What Are GitHub Agentic Workflows? On February 13, 2026, GitHub released this as a technical preview. Co-developed by GitHub Next, Microsoft Research, and Azure Core Upstream, it’s open source under the MIT license. In short, a mechanism for automatically running AI coding agents on GitHub Actions. ...

この記事で分かること GitHub Agentic Workflowsとは何か 従来のGitHub Actionsとの違い Claude Codeユーザーにとっての導入メリット 20万行SaaSプロジェクトで何を自動化できそうか 導入判断のポイント GitHub Agentic Workflowsとは 2026年2月13日、GitHubがtechnical previewとして公開した新機能。GitHub Next、Microsoft Research、Azure Core Upstreamの共同開発で、MITライセンスのオープンソース。 一言で言うと、GitHub Actions上でAIコーディングエージェントを自動実行する仕組み。 従来のGitHub Actionsは「こうなったら、こうしろ」をYAMLで厳密に定義する。Agentic Workflowsは「こうなったら、こういう判断をしてほしい」をMarkdownで書く。判断はAIが行う。 従来のGitHub Actions: イベント → YAML定義の手順 → 決定的な実行 Agentic Workflows: イベント → Markdown記述の目的 → AIが判断して実行 仕組み ワークフローの定義 .github/workflows/ にMarkdownファイルを置く。YAMLではなくMarkdown。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 --- on: issues: opened permissions: contents: read issues: write safe-outputs: add-comment: true add-labels: true engine: claude --- ## Issue Triage 新しいIssueが作成されたら、内容を分析して適切なラベルを付ける。 ## 判断基準 - バグ報告 → `bug` ラベル - 機能要望 → `enhancement` ラベル - 質問 → `question` ラベル - セキュリティ関連 → `security` ラベル + 優先度を上げる ## コメント トリアージ結果をコメントとして残す。 フロントマターでトリガー、権限、使用するAIエンジンを指定し、本文に自然言語で「何をしてほしいか」を書く。 ...

What You Will Learn Problem and solution patterns in self-hosted runner environments How to prevent resource contention on a shared Docker daemon The port assignment problem killed by the birthday paradox How to investigate when “CI that was working suddenly breaks” Introduction In Part 2, I wrote about automating E2E tests using WebAuthn and Mailpit. The tests themselves work fine. The problem was the CI infrastructure. Saru has 4 frontends x 4 backend APIs. E2E tests run independently for each portal, plus there are cross-portal tests (integration tests between portals). Running these in parallel means 7+ jobs executing simultaneously. ...

この記事で得られること セルフホストランナー環境で起きる問題と対策パターン 共有Docker daemonでのリソース競合の防ぎ方 誕生日のパラドックスに殺されるポート割り当ての話 「動いていたCIが突然壊れる」原因の調査手法 はじめに 第2回で、WebAuthnやMailpitを使ったE2Eテスト自動化について書いた。テスト自体は問題なく動く。問題はCIインフラの方だった。 Saruは4つのフロントエンド × 4つのバックエンドAPIを持つ。E2Eテストは各ポータルごとに独立して実行し、さらにクロスポータルテスト（ポータル間の連携テスト）もある。これらを並列実行すると、7つ以上のジョブが同時に走る。 当初はGitHub-hostedランナーを使っていたが、E2Eテストにはデータベース、Keycloak、メールサーバーが必要で、Dockerコンテナを大量に起動する。GitHub-hostedでは毎回のセットアップに時間がかかり、並列実行のコスト効率も悪い。 そこでセルフホストランナーに移行した。その判断は正しかったが、新しい種類の問題が大量に発生した。 本記事では、セルフホストCI環境で遭遇した問題と、その解決策を時系列で記録する。同じ構成を採用する人の参考になれば幸いだ。 1. Docker Desktop/WSL2が不安定すぎた 最初の構成 最初はWindows上のDocker Desktop（WSL2バックエンド）でランナーを動かしていた。構成はシンプルだ： Windows Host └─ WSL2 └─ Docker Desktop └─ GitHub Actions Runner × N 問題は「コンテナがランダムに死ぬ」こと。E2Eテスト中にPostgreSQLコンテナが突然消えたり、Keycloakが応答しなくなったりする。docker inspectするとExit Code: 137（SIGKILL）で殺されている。 原因を追うと、Docker Desktop/WSL2の仮想化レイヤーが問題だった： コンテナ → Docker Engine → WSL2 → Hyper-V → Windows WSL2自体がHyper-Vの軽量VMとして動いており、そこにさらにDockerが乗る。メモリプレッシャーが高まるとWSL2がOOM Killerを発動し、Dockerコンテナが無差別に殺される。 Hyper-V VMへの移行 解決策として、WSL2を経由せず直接Hyper-V上にUbuntu VMを立てた： コンテナ → Docker Engine → Ubuntu VM → Hyper-V → Windows 項目 値 VM名 saru-ci-runner OS Ubuntu 24.04 vCPU 16 メモリ 64GB ディスク 200GB ネットワーク External Switch（ブリッジ） Hyper-V VMの方が仮想化レイヤーが少なく、メモリ管理もWSL2より安定している。WSL2は動的メモリ割り当てで「ホストと共有」する（デフォルトでホストRAMの50%または8GBまで）が、Hyper-V VMは固定メモリを割り当てるため、OOM Killerに殺されるリスクが低い。 ...