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専用タ
本人アカウントと委任アカウントが同じ機能を触るとき、権限チェックをどう一本化するか新着!!
「本人アカウント」と「権限レベル付きの委任アカウント」が同じサブリソースを操作するシステムでは、権限ごとにできる操作の境界をどう管理するかが地味に難しくなります。委任アカウントに view / approve / edit のような段階的な権限を持たせるケースは珍しくありませんが、機能を1つ追加するたびに権限判定のロジックをあちこちに書き散らかしてしまうと、どこかで権限漏れが起きるリスクが高まりま
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は本文を自分たちの都合で書けないため、検査対象から外したい、というものです。
CLIの「エラーは出ているはずなのに何も表示されない」を追ったら見えた4つの罠
社内向けのCLIツールで、「エラーは出ているはずなのに何も表示されず、終了コードだけがおかしい」という不具合を追いかけたことはないでしょうか。