CI/CD基盤のコスト削減とDocker Hubのレートリミットを回避するためのミラーサーバーを導入した話 - DeNA Testing Blog
こんにちは、SWETの川口 ( @yamoyamoto ) です。SWETではCI/CDチームの一員として、GitHub Actionsセルフホストランナー基盤の開発・運用に取り組んでいます。 今回は、私たちのチームがDocker Hubのレートリミット回避とコスト削減のためにミラーサーバーを導入した事例を共有したいと思います。 目次 はじめに 課題解決に向けた検討 既存ソリューションの検討 Google Cloud - Artifact Registry （mirror.gcr.io） AWS - Amazon ECR Public Distribution を利用したミラーサーバーの構築 Distribution について リクエストの処理フロー 検討が必要だったポイント ストレージの選定とパフォーマンス検証 S3、filesystemの構成 S3の場合 filesystemの場合 ミ
Actions Performance Metrics in public preview · GitHub Changelog
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
やんないほうがいいかも、GitHub Actions の setup-xxx での依存キャッシュ保存 - 誰かの役に立てばいいブログ
GitHub Actions で CI している皆様、こんにちは。 GitHub Actions 便利ですよね。使わない日がないというくらい毎日お世話になっています。 さて、CI といえば良く問題になるのが実行時間。 長い待ち時間は開発効率を下げますし、プライベートリポジトリだと Runner の費用も嵩んでしまいます。 時間を短縮する方法は色々ありますが、一手目によく行われるのが依存パッケージのキャッシュじゃないかなと思います。 例えば Go で開発していると、依存パッケージは ~/go/pkg/mod にダウンロードして保存されます。 これを CI 実行のたびにダウンロードしてコンパイルするのは時間とお金の無駄というものです。 幸い、GitHub Actions には CI の実行間でこういった依存パッケージを保存して再利用できるキャッシュ機能があります。 詳しくは以下のドキュメントを
GitHub Actions の実行履歴に基づいて自動で timeout-minutes を設定
GitHub Actions の timeout-minutes を自動で設定する ghatm という OSS を開発しています。 workflow の実行履歴を GitHub API で取得し job 毎に適切な timeout-minutes を設定する機能をリリースしたので紹介します。 要約 ghatm v0.3.2 で GitHub Actions の実行履歴に基づいて自動で timeout-minutes を設定する機能をリリース job ごとに適切な timeout-minutes を設定するのは大変なので、自動化できると便利 ghatm set -auto [-repo <owner>/<repo>] [-size <job のサンプリング数 | デフォルト 30>] workflow_call 非対応など、まだまだ改善の余地あり 導入 元々 ghatm は timeout-
GitHub Actions Cache Server
Easily deploy your own GitHub actions cache without needing to change any workflow files! services: cache-server: image: ghcr.io/falcondev-oss/github-actions-cache-server:latest ports: - '3000:3000' environment: API_BASE_URL: http://localhost:3000 volumes: - cache-data:/app/.data volumes: cache-data:
GitHub Actions の timeout-minutes の linter 及び一括設定ツール
GitHub Actions の timeout-minutes に関する lint rule 及び一括で timeout-minutes を設定するツールを作ったので紹介します。 timeout-minutes とは timeout-minutes は GitHub Actions の job 及び step (workflow は対応していないはず) の設定項目の一つで、 job 及び step のタイムアウトです。 timeout-minutes で設定した時間以内に job 及び step が完了しない場合に強制的に終了し失敗扱いになります。 デフォルトは 360 分です。 ただし、 reusable workflow を使っている job は timeout-minutes をサポートしていません。 なぜ timeout-minutes を設定すべきなのか デフォルトの 6 時間
GitHub Actions 上での Go の Docker ビルドを高速化する
どうも GitHub Actions 上で Docker ビルドを行うと時間がかかるなぁと感じていました。 かなり軽量の Go の Web アプリケーションを Docker イメージにしてプッシュするプロセスなのですが、全体で 3 分ほどかかっています。 今回はその速度改善を行ったので、得た知見を記事にしたいと思います。 最終的に、ケース次第では以下のような結果を出すことができました。 ※ケース = go のソースコードのほんの一部を変更してワークフローを実行する。 go.mod など依存関係に変化はない。 go build: 60秒 → 1秒 docker/build-push-action ステップ: 2分30秒 → 30秒 ワークフロー: 3分 → 1分 前提 go build は Dockerfile のステップで行っており、イメージとして以下のような内容になっています。 FROM
actions/cache@v4ではヒットしなかったときcache-hit=='false'にならない - ぽよメモ
[追記 2024/8/1] 修正のPRがマージされました [追記 2024/10/9] 修正がリバートされました cache-hitとは v4における挙動変更（？） cache-hitがfalseを返さない ワークアラウンド [追記 2024/8/1] 修正のPRがマージされました まだリリースされていませんが次のリリースに含まれるでしょう。 github.com [追記 2024/10/9] 修正がリバートされました v4.1.0で修正された本変更だが、空文字になるという挙動に依存していた人が予想よりも多く、元の挙動に戻すという決定がされた。 github.com v4.1.1ではこの記事の通り cache-hit=='false' にならず、空文字が返る。 詳しくは以下のコメントを参照して欲しいが、そもそも cache-hit というパラメータの表すものが難しく、将来的にはパラメータの
業務で使えるかもしれない…！？GitHub Actions の Tips 集 / CI/CD Test Night #7
Event https://testnight.connpass.com/event/311263/ Archive https://youtu.be/96KUNLiMe6w?t=327
PATを使わずにGithub Appを使ってGithub ActionsでPrivate Repoを参照する話
このブラウザ バージョンのサポートは終了しました。サポートされているブラウザにアップグレードしてください。
GitHub ActionsでファイルをS3にキャッシュするアクションを作りました - プログラムモグモグ
GitHub Actionsでは依存パッケージやビルド結果などをうまくキャッシュすることで、テストやビルドの時間を短縮できます。 actions/setup-nodeやactions/setup-javaなどの各言語のオフィシャルアクションは各パッケージマネージャーのためのキャッシュ機構を提供していますし、actions/cacheを使って任意のファイルをキャッシュすることもできます。 これらは内部で@actions/cacheパッケージを使っており、キャッシュの機構はGitHub自身の機能と密に結びついています。 しかし、GitHub Actionsのキャッシュはリポジトリごとに10GBまでという制限があり、開発者の多いリポジトリではsetup-nodeのキャッシュだけでもすぐに上限に達してしまいます。 私の所属するチームのリポジトリはGitHub Enterprise Serverにホ
【DeNATechCon2024】CI/CD の課題解消！ GitHub Actions への移行で可能になったこと | ドクセル
【DeNATechCon2024】CI/CD の課題解消！ GitHub Actions への移行で可能になったこと スライド概要 私たちのチームは長年、Circle CI と Jenkins を活用して CI/CD 環境を構築してきました。しかし、運用の複雑さと高コストに直面し、より効率的な方法を模索していました。この問題を解決するために、GitHub Actions への移行を決定しました。その結果、運用コストの削減と操作の簡易性を実現しました。 本登壇では、私たちが既存の CI/CD を GitHub Actions に移行する過程で直面した課題と、それらをどのように解決したか、なぜこのタイミングになったのかなどを共有します。本登壇が、同様の問題に直面しているエンジニアの皆さんに具体的な解決のヒントとなることを願っています。 ※資料内の動画は後日公開されるセッション動画でご覧いただけ
フロントエンドのGitHub Actions実行時間を削減するために取り組んだこと | PR TIMES 開発者ブログ
こんにちは、フロントエンドエンジニアの小張です。GitHub Actionsの実行時間を削減するために取り組んだことについて紹介します。 経緯 PR TIMESではReactに関するコードを、monorepoとしてprtimes-frontendという1つのリポジトリで管理しています。 GitHub Enterprise Cloudプランでは月50,000分のGitHub Actionsを無料で実行することができますが、prtimes-frontendだけで7割近い時間を消費してしまっていました。またCIに時間がかかることで、Pull Requestを作成した後、10分近く待たないとコードレビューに回すことができず、開発効率が落ちてしまっていました。 そこで現状の使い方を見直して、billable timeの削減に取り組むことになりました。 billable time削減の改善点を探す b
GHES の GitHub Actions で Google Cloud との OIDC 連携がしやすくなりました
みなさん GitHub Actions の OpenID Connect (以下OIDC) 連携使っていますか？ GitHub Actions はワークフローの中で OIDC の ID トークンを発行でき，これを Google Cloud などのクラウドプロバイダの認証に用いることでサービスアカウントのクレデンシャルを発行することなくクラウドプロバイダのリソースをワークフロー内で操作できるようになります．これによりクレデンシャルのローテーションなどの管理コストが減り，よりセキュアな連携が可能になります． 詳しくは GitHub の公式ドキュメントや解説記事を見ていただけると良いと思います． 基本的に良いことづくめな OIDC 連携ですが，GitHub Enterprise Server (オンプレ版 GitHub．以下GHES) では OIDC 連携が難しいケースがあります．OIDC 連携
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
持続可能なソフトウェア開発を支える『GitHub CI/CD実践ガイド』
Copilot Enterprise now helps you fix failed Actions jobs, plus other August updates (public beta) · GitHub Changelog
GitHub - suzuki-shunsuke/ghatm: Set timeout-minutes to all GitHub Actions jobs
Contributing to Exercism | Exercism's Docs
Actions Runner Controller Deep Dive
Ubicloud - GitHub Actions, 10x Cheaper
