CIのクリティカルパスを壊さずにsqliteで時系列メトリクスを蓄積する設計新着!!
CIホストのようなインフラでは、「ジョブの取得・解放」や「死活監視」といったクリティカルパスに手を加えるのはとてもリスクが高い作業です。ログに障害の兆候を出力するだけなら簡単ですが、「Dockerイメージの容量が右肩上がりになっていないか」「同時実行の枠が足りているか」といったトレンドを判断するには、時系列で数値を蓄積する仕組みが必要になります。
fix(ci): macOS Lighthouse の NO_FCP を背景化抑止フラグで解消する新着!!
CIでLighthouseをヘッドレスChromeで回していると、macOS環境でだけ`NO_FCP`（First Contentful Paintが観測できない）エラーが断続的に発生することがあります。ログを見ても、通信エラーやアプリ側の描画バグを示す手がかりは見つかりません。
npm未publishの内部パッケージをvendoringで配る:取り込み元の追跡と改変検知を自動化する設計新着!!
npmにもGitHub Packagesにも公開しない方針の社内限定ライブラリを、複数のリポジトリが `vendor/` 配下に手でコピーして参照する構成は珍しくありません。ただし手コピーには弱点があります。どのコミットから持ってきたコードなのか、コピーしたあとに誰かが手を加えていないか、を追跡する手段がどこにもないのです。
デプロイ後スモークテストの「全断」誤判定、原因は失敗理由をひとまとめに扱っていたこと新着!!
デプロイ後に自動で「サイトが生きているか」を確認するスモークテストは、多くのチームで導入されている仕組みだと思います。ただ、運用を続けていると、意外な落とし穴に気づくことがあります。
E2Eテストの「検疫タグ」運用を形骸化させない設計新着!!
E2Eテストを「PRごとに回す高速レーン」と「毎晩フルで回すnightly」に分けて運用しているチームは少なくないと思います。この運用を続けていると、いずれ「重いテストケースだけをnightlyに退避する」検疫の仕組みが必要になってきます。あるプロジェクトでは、2コアのようにリソースが絞られたCIランナー上で一部のE2Eケースがtimeoutするようになり、該当ケースだけを再度nightly専用タ
本人アカウントと委任アカウントが同じ機能を触るとき、権限チェックをどう一本化するか新着!!
本人アカウントと権限レベル付き委任アカウントが同じ機能を操作するシステムで、権限チェックのロジックを一本化する設計パターンを解説します。承認処理と作成処理で同じ権限判定関数を再利用し、権限漏れを防ぐ実装例を紹介します。
CLIの起動判定がCIでだけ失敗する謎—TTY検出で出力形式が変わる罠新着!!
CLIはTTY接続の有無で出力形式を変えることがあり、これがE2EテストのCI環境でのみ起動判定が失敗する原因に。この謎を解き明かし、起動待ち判定の切り分け方と、原因の見えにくい不具合を解決するアプローチを解説します。
複数リポジトリのセキュリティCIをreusable workflowで一本化する
複数のリポジトリを運用していると、SAST・シークレットスキャン・依存脆弱性チェックといったセキュリティ系のCIを、リポジトリごとに個別実装してしまいがちです。
GitHub Actionsのrequired status checkでbotのPRだけ免除したい時にハマった2つの罠
Reusable GitHub Actions workflowでPRのタイトルや本文の書式を検査するjobを組んでいると、必ずと言っていいほど直面する問題があります。Dependabotのようなbotが作るPRは本文を自分たちの都合で書けないため、検査対象から外したい、というものです。
