OpenCI ランナーを使えば、GitHub Actionsのコストを大幅に下げ、CI/CDの処理速度を向上させることができます。
OpenCI ランナー 🇯🇵 - 国産のオープンソースなサードパーティ GitHubランナー
OpenCI ランナーを使えば、GitHub Actionsのコストを大幅に下げ、CI/CDの処理速度を向上させることができます。
Self-Hosted Runnerで GitHub Actions のCI/CDを高速化・コスト最適化した
はじめに Dress Code Advent Calendar 2025 の10日目の記事です。 GitHub Actionsは非常に便利なCI/CDツールですが、プロジェクトが成長するにつれて、GitHub-hosted runnersだけでは対応しきれない課題に直面することがあります。 本記事では、AWS上にSelf-Hosted Runnerを構築し、CI/CDパイプラインの高速化とコスト最適化を実現した取り組みについて紹介します。同様の課題を抱えている方の参考になれば幸いです。 背景・課題 私たちのプロジェクトでは、GitHub-hosted runnersを使用する中でいくつかの課題が顕在化していました。 リソース不足 プロジェクトの規模が大きくなるにつれ、ビルドやテストに必要なCPUとメモリが増加しました。特にNode.jsアプリケーションの大規模なビルドでは、GitHub-h
oxlint, oxfmt, tsgoを導入して開発環境が爆速になった
はじめに こんにちは。ぷーじ（@yug1224）です。 Dress Code Advent Calendar 2025 24日目の記事です🎄 フロントエンド・バックエンド開発において、リンター、フォーマッター、型チェッカーはコード品質を担保する上で欠かせないツールですよね。しかし、プロジェクトの規模が大きくなるにつれ、これらのツールの実行時間がCI/CDのボトルネックになることがあります。 私たちのプロジェクトはTypeScriptファイルだけで1万ファイル以上という規模であり、まさにこの問題に直面していました。 今回、Rust製の高速ツールチェーンであるoxc（Oxidation Compiler） と、TypeScript公式のTypeScript Native Preview（tsgo） を導入することで、CI時間を大幅に削減しました！ この記事では、導入の背景、実際の改善結果、そ
npm ciのキャッシュ方式の検討
結論から言うと、node_modulesをキャッシュしてnpm ciの実行を省略するのが、多くの場合には有効そうです。 はじめに CIで npm ci を使うとき、実行時間短縮のためにキャッシュの利用を検討することになると思います。このとき、どのようにキャッシュするのが良いのでしょうか？ よく知られているキャッシュ方式として、以下の二通りの方式があります。 ~/.npmをキャッシュする方式 node_modulesをキャッシュする方式 それぞれの違いについて、詳しく見てみましょう。 ~/.npmをキャッシュする方式 npm ci を実行すると、POSIX系のOSではデフォルトで ~/.npm にキャッシュデータが書き込まれます。package-lock.json をキーにこのディレクトリをキャッシュしておくことで、次回以降の npm ci 実行時にこのキャッシュデータを利用しよう、というの
Nx の攻撃から学べること #s1ngularity | blog.jxck.io
Intro Nx リポジトリが攻撃を受け、広範囲にわたるインシデントが発生した。 今回の事例は、GitHub Actions を中心に複数のステップが組み合わさった攻撃であり、過去に何度も発生してきた攻撃と本質的には変わらない。 しかし、途中で AI が何度か登場するため「AI が書いたコードをマージしたから」などといった表面的な反応もあるが、実態はそこまで単純な話でもない。 また、「自分のプロジェクトは Nx を使っていないから関係ない」とも言えない攻撃であるため、特にフロントエンドエンジニアは全員注意と確認が必要となる。 この攻撃が何だったのか、そこから学べることは何なのか、解説する。 Nx Incident 今回のインシデントについては、既に公式の Advisory が出ている。ニュース系の記事も多々あるが、一次情報は以下となる。 Malicious versions of Nx a
Environmentを使ってGitHub ActionsのDeploy先を切り替える
これらはDeploy頻度も違えば、Deployされるソースコードにも違いがあります。そのため、CI/CDの処理も環境によって微妙に異なってきます。具体的には以下のようなものがあるでしょう。 環境変数 Buildコマンド Deploy先 権限 しかし、基本的な処理が大きく変わるということはあまりないです。 GitHub ActionsのSecrets/Variables GitHub Actionsには、ハードコーディングしたくない値を保存する機能として、SecretsとVariablesがあります。これは環境変数のようなもので、GitHub Actionsを構成するYAMLファイルから参照できます。 Secrets Secretsは名前からもわかるとおり、機密情報を保存するための環境変数のようなものです。Secretsに保存された値は後から確認することができず、GitHub Actions
やんないほうがいいかも、GitHub Actions の setup-xxx での依存キャッシュ保存 - 誰かの役に立てばいいブログ
GitHub Actions で CI している皆様、こんにちは。 GitHub Actions 便利ですよね。使わない日がないというくらい毎日お世話になっています。 さて、CI といえば良く問題になるのが実行時間。 長い待ち時間は開発効率を下げますし、プライベートリポジトリだと Runner の費用も嵩んでしまいます。 時間を短縮する方法は色々ありますが、一手目によく行われるのが依存パッケージのキャッシュじゃないかなと思います。 例えば Go で開発していると、依存パッケージは ~/go/pkg/mod にダウンロードして保存されます。 これを CI 実行のたびにダウンロードしてコンパイルするのは時間とお金の無駄というものです。 幸い、GitHub Actions には CI の実行間でこういった依存パッケージを保存して再利用できるキャッシュ機能があります。 詳しくは以下のドキュメントを
docker buildx bake で高速並列ビルド - 誰かの役に立てばいいブログ
Docker ビルド職人の朝は早いーー 毎日コンテナイメージを山ほどビルドしては捨てている皆様、おはようございます。 ビルドの速度はそのまま CI にかかる時間だったりするので、短縮には余念のないことと思います。 レイヤのキャッシュやマルチステージビルドといった基本テクニックについて、ご存じない方は以下の記事がお勧めです。 future-architect.github.io この記事では、良い Dockerfile をさらに活用できる、かもしれない docker buildx bake について紹介します。 bake の紹介の前に、私が抱えていた問題を説明します。 目下のプロジェクトでは Kubernetes 上で多数のマイクロサービスを動作させています。 マイクロサービス群はモノリポ（monorepo）上の共通のフレームワークやライブラリを用いて効率的に開発されています。 そのため、全
GitHub Self-hostedに移行しました。CIが最大55%速くなり、月額が300万円節約できた！
こんにちは、SODAのSREチームのDucと申します。 GitHub Actionsのコストを削減しながらCIワークフローを高速化したの工夫をご紹介します。 背景 私たちのチームは、snkrdunk.comサイトとSNKRDUNKモバイルアプリの可用性とパフォーマンスの維持に注力しています。 それに加えて、クラウドインフラストラクチャやその他の監視・開発ツールのコスト管理も担当しています。 毎月、AWSやGitHubなどのインフラストラクチャとツールの請求書をチェックしています。 GitHubの請求額が非常に高いことに気づきました。特にGitHub Actionsの部分です。 参考までに、GitHub Actionの使用量とサーバーの本番ワークロード費用の比較をご紹介します。 Fargate: Savings Plan適用で月額約$7,000。私たちのサービスは平均約5000リクエスト/秒
GitHub ActionsのJobが落ちたときに何をするべきかを記述するPlaybookの仕組みを作って運用している話 - newmo 技術ブログ
newmoではGitHub Actionsを自動テスト、Lint、デプロイなどに利用しています。 また、newmoではmonorepoで開発しているため、1つのリポジトリに複数のチーム/複数のアプリケーションが存在しています。 GitHub Actionsではpathsを使うことで、特定のファイルが変更された場合のみ特定のWorkflowが実行できます。 newmoのmonorepoのworkflowでは基本的にpathsが指定されていますが、それでも普段は触らないファイルを変更して意図せずにCIが落ちることがあります。 GitHub ActionsのCIが落ちたときに、そのCIの仕組みを作った人やチーム以外だと何をすべきかわからないことがあります。 この問題の解決するを手助けするシンプルな仕組みとして、GitHub ActionsにCIが落ちたときに何をするべきかを表示するPlayboo
ローカルで GitHub Actions が実行できる act のお作法を整理する
はじめに GitHub Actions (GHA) 、便利ですね。 便利なんですが、動作確認するのに PR 出してマージするのが煩わしい...。そもそも PR する前に動作確認しておきたいし、やたらに PR 作りたくもない...。 そんな悩みを解消してくれるのが act でした。これならローカルで動作確認できるので GHA 開発が捗ります！！ act 使ってみた記事は沢山ありますが、動かすまでに詰まったポイントをお作法として整理 してみました。act の使い方に悩まれている方の参考になれば幸いです。 2024/5/8 追記 act の実行に IAM ロールに追加設定が必要な点を追記しました。 AssumeRole するために sts:TagSession 権限を付与する 対象読者 GitHub Actions を使っている / 使おうとしている方 GitHub Actions の動作確認に
なんとなくから脱却する GitHub Actionsグッドプラクティス11選 | gihyo.jp
本記事のテーマはGitHub Actionsです。個人的に「もっと早く知りたかった！」と考えているグッドプラクティスを、厳選してお届けします。想定読者は次のとおりです。 普段GitHub Actionsを雰囲気で運用している人 GitHub Actionsをコピペや生成AIで乗り切っている人 他者が書いたコードの意味をより深く理解したい人 本記事でGitHub Actionsの基本は説明しません。グッドプラクティスを含めて基礎から学びたい人は、拙著『GitHub CI/CD実践ガイド』を読んでみてください。GitHub Actionsの基本構文から運用のコツまで、網羅的に解説しています。さて書籍紹介はこれぐらいにして、さっそく本題へ進みます。 GitHub Actionsの設計指針 GitHub ActionsはCI/CDや各種自動化で役立つ、汎用的なワークフローエンジンです。一般的に長期
GitHub Actionsで定期実行（cron）のワークフローを組んだユーザーが退職すると、ワークフローは無効化される - shmokmt's blog
GitHub Actionsで定期実行（cron）のワークフローを組んだユーザーが退職すると、ワークフローは無効化される 大事なことなので、見出しでも同じことを書いてしまいました。 何を言っているんだという感じですが、とにかくそういうことらしいです。 厳密には最後にワークフローにコミットしたユーザーが組織から削除されると、無効になるようです。 GitHub Actionsの定期実行でPR作成を自動化*1している会社もそれなりにあるかと思うのですが、その場合はそれらが全部停まります。 さらに、1度無効化されてしまった場合はcron式を変更しないといけないというのも罠ポイントですね。 最後にワークフローの Cron スケジュールにコミットしたユーザーが組織から削除されると、スケジュールされたワークフローは無効になります。 リポジトリへの write アクセス許可を持つユーザーが Cron スケ
GitHub Actions 上での Go の Docker ビルドを高速化する
2025-01-08 追記 さらに高速化について検証されている記事が公開されていました！ 引用させていただきます。 どうも GitHub Actions 上で Docker ビルドを行うと時間がかかるなぁと感じていました。 かなり軽量の Go の Web アプリケーションを Docker イメージにしてプッシュするプロセスなのですが、全体で 3 分ほどかかっています。 今回はその速度改善を行ったので、得た知見を記事にしたいと思います。 最終的に、ケース次第では以下のような結果を出すことができました。 ※ケース = go のソースコードのほんの一部を変更してワークフローを実行する。 go.mod など依存関係に変化はない。 go build: 60秒 → 1秒 docker/build-push-action ステップ: 2分30秒 → 30秒 ワークフロー: 3分 → 1分 前提 go b
日本ではKubernetesやCI/CDなどが幻滅期に、インダストリクラウドやインフラ自動化は過度な期待。「日本におけるクラウド・プラットフォームのハイプ・サイクル」2024年版発表
日本ではKubernetesやCI/CDなどが幻滅期に、インダストリクラウドやインフラ自動化は過度な期待。「日本におけるクラウド・プラットフォームのハイプ・サイクル」2024年版発表 調査会社のガートナージャパンは、「日本におけるクラウド・プラットフォームのハイプ・サイクル：2024年」を発表しました。 ハイプサイクルとは ガートナーのハイプサイクルは、技術の登場から安定までを5つのステージに分けて説明したものです。5つのステージは、「黎明期」から始まり、「『過度な期待』のピーク期」「幻滅期」「啓発期」「生産性の安定期」まで。この途中で消えていく技術もあります。 同社はグローバルだけでなく国別などさまざまな切り口でハイプサイクルを発表しています。今回発表されたのは日本のクラウドプラットフォームにおけるハイプサイクルです。横幅の関係上、図を2つに分割しました。まずは前半部分。 黎明期にはFi
ジャイアントパンダに注意 - Next.js のビルド改善 (株式会社GiXo様)
最近になって Frontend Ops の傭兵として活動を始めました。 Frontend Ops 実践のモデルケースとして、 株式会社GiXo様で Next.js 仕事に取り組ませいただきました。今回、その内容を公開する許可を頂けたので、事例として公開させていただきます。 依頼主 株式会社GiXo様 以下、敬称略 相談内容 フロントエンド関連のリポジトリで、Next.js のビルドが遅くなってしまった。 重いことに起因して Vercel CI で OOM で確率的に落ちるようになった。CIが信用できなくなり、とりあえず再ビルドするクセがついてしまって、生産性が落ちている。 モノレポ内にとくに重いアプリケーションが一つあり、これを調査・解決してほしい。 仮ゴール: VercelCI 上のビルド時間を半分OOM が発生しないようにしたい 調査フェーズ リポジトリの閲覧権を頂き、プロジェクト構成
GitHub - stackblitz-labs/pkg.pr.new: 📦️ Continuous (Preview) Releases for your libraries!
We call it "Continuous Releases" too. With pkg.pr.new, each of your commits and pull requests will trigger an instant preview release without publishing anything to NPM. This enables users to access features and bug-fixes without the need to wait for release cycles using npm or pull request merges. 🚀 Instant Builds 🍕 No Need for NPM Access 🛠️ GitHub Workflows Friendly 📦️ No Configuration 🔩 Si
CI/CDのデータを収集するCIAnalyzerの紹介
去年のGWにCIAnalyzerというツールを作成し、プライベートと仕事の両方で1年ほど活用してきました。今年の9月にCI/CD Conference 2021にて実際の活用事例を紹介させて頂きましたが、発表時間の都合上CIAnalyzer自体の使い方まで紹介はできなかったためブログにしました。 CIAnalyzerを作成したきっかけ 今の自分の仕事は社内のCI/CDの基盤を整えるのと同時に、ビルドエンジニアの真似事のようなことをしています。この分野のサポートをしていると開発を主にしているエンジニアの方から 「ビルドが遅いし、頻繁に壊れる」 「テストは時間がかかるし、いつも失敗している」 という話を聞く機会がありました。ですが、自分としてはとても意外なことにその実態を定量的に把握することはほとんどできませんでした。 もちろん短期的であれば把握できます。昨日のデプロイはN分かかったとか、ma
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Hotwire or React? ~Reactの録画機能をHotwireに置き換えて得られた知見~ / hotwire_or_react
あなたのパフォーマンスを倍にする Frontend Ops の傭兵はいかがですか
