Evaluating GitHub Agentic Workflows — From a Claude Code User's Perspective [Part 10]

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. ...

February 17, 2026 · 7 分 · ko-chan

GitHub Agentic Workflowsの導入を検討してみた — Claude Codeユーザーの視点から [第10回]

この記事で分かること 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エンジンを指定し、本文に自然言語で「何をしてほしいか」を書く。 ...

February 17, 2026 · 3 分 · ko-chan

Landmines and Solutions in Self-Hosted CI/CD: 15 Runners x Shared Docker Environment [Part 7]

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. ...

February 12, 2026 · 12 分 · ko-chan

セルフホストCI/CDで踏んだ地雷と解決策:15ランナー × 共有Docker環境の闘い【第7回】

この記事で得られること セルフホストランナー環境で起きる問題と対策パターン 共有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に殺されるリスクが低い。 ...

February 12, 2026 · 5 分 · ko-chan

Testing WebAuthn in CI: E2E Automation with Virtual Authenticators and Mailpit [Part 2]

What You’ll Learn How to test WebAuthn (passkey) authentication in CI environments Automating OTP email retrieval with Mailpit API Preventing email race conditions in parallel E2E tests Locale-specific testing for multilingual UIs Introduction In Part 1, I introduced the overall architecture and automation strategy for “Saru,” a multi-tenant SaaS platform. This article dives deeper into the E2E testing implementation that forms the core of that automation. The most challenging aspect is testing authentication flows. Saru uses two authentication methods: ...

January 13, 2026 · 8 分 · ko-chan

WebAuthn認証をCIで自動テスト:仮想認証器とMailpit連携で実現するE2E【第2回】

この記事で得られること WebAuthn(パスキー)認証をCI環境でテストする方法 OTPメール取得の自動化(Mailpit API連携) 並列E2Eテストでのメール競合を防ぐテクニック 日本語UIを直接テストするlocale-specific testing はじめに 第1回では、マルチテナントSaaS「Saru」の全体像と自動化戦略を紹介した。今回は、その自動化の核となるE2Eテストの実装詳細を掘り下げる。 特に難しいのが認証フローのテストだ。Saruでは2種類の認証方式を採用している: ポータル 認証方式 難しさ System / Provider OTP + パスキー メール取得、WebAuthn Reseller / Consumer Keycloak OAuth 外部IdP連携 これらをすべてCIで自動テストする方法を解説する。 1. WebAuthn仮想認証器:パスキーをCIでテスト パスキー認証の課題 WebAuthn(パスキー)は物理的なセキュリティキーや生体認証を使う。普通に考えると、CI環境でテストするのは不可能に思える。 解決策:Chrome DevTools Protocol (CDP) の仮想認証器 Playwrightでは、CDPを通じて仮想的な認証器を作成できる。これにより、物理デバイスなしでWebAuthnのフルフローをテストできる。 注意: CDP仮想認証器はChromium系ブラウザ限定の機能。Safari(WebKit)やFirefoxでは使用できない。クロスブラウザ対応が必要な場合、WebAuthnテストはChromiumでのみ実行し、他ブラウザでは認証済み状態をモックする等の対策が必要になる。 実装コード 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 27 28 29 30 import { test, expect, type BrowserContext } from '@playwright/test'; test('should complete signup with Passkey registration', async ({ page, context }) => { // 仮想認証器を有効化 const cdpSession = await context.newCDPSession(page); await cdpSession.send('WebAuthn.enable'); // 仮想認証器を追加 await cdpSession.send('WebAuthn.addVirtualAuthenticator', { options: { protocol: 'ctap2', // CTAP2プロトコル transport: 'usb', // USB接続をエミュレート hasResidentKey: true, // パスキー対応 hasUserVerification: true, // 生体認証をエミュレート isUserVerified: true, // 常に認証成功 automaticPresenceSimulation: true, // 自動応答 }, }); // ... サインアップフローを実行 ... // Passkey登録ボタンをクリック await page.getByRole('button', { name: 'Passkey' }).click(); // 仮想認証器が自動的に応答し、登録が完了する await expect(page.getByText('Passkey registered')).toBeVisible(); // クリーンアップ await cdpSession.send('WebAuthn.disable'); }); transport設定とサーバー設定の整合性 WebAuthn仮想認証器を設定する際、サーバー側の設定との整合性が重要になる。 ...

January 13, 2026 · 4 分 · ko-chan