tech.guitarrapc.cóm

Technical updates

GitHub Actionsのhosted runnerサイズを使い分ける

本日(2026年1月2日)から、Hosted Runnerの値下げが有効になりました。 いい機会なので、GitHub Actionsのhosted runner(Ubuntuランナー)における、ubuntu-24.04ubuntu-slimの使い分けについて振り返っておきましょう。

対象

本記事の対象は、Private RepositoryでGitHub Actionsを利用している方です。

Public Repositoryは無料でランナーが使えるため、slimにする強い動機づけがありません。ただ、処理が軽量な場合はubuntu-slimを使うことでGitHubのリソース消費を抑えられます1。あるいは1Coreのパフォーマンスを検証するのに、試すのもいいでしょう。

ubuntu-slimの概要

スペックをおさらいしておきましょう。

簡単にまとめると、次の特徴があります。

  • VMではなくコンテナで起動
  • 1CPUコア、5GBメモリ
  • 15分上限の実行時間
  • 最小限のツールセットだけプリインストール

以下はプライベートリポジトリにおける、ランナーのスペックです。slimはCPUが少なく、メモリも少ないのでCPUを複数使うビルド処理などには向いていません。また、VMではなくコンテナで起動しており、最大15分までしか実行できません。参考に載せたCPU4コアは、Larger Runnersオプションで利用可能です。

  • ubuntu-slimランナー: CPU1コア、メモリ5GBのx64コンテナ
  • ubuntu-24.04ランナー: CPU2コア、メモリ7GBのx64マシン2
  • ubuntu-24.04-4core: CPU4コア、メモリ16GBのx64マシン

2026/1/2から、コストは次の通りです。ubuntu-slimは安くなっていないのですが、依然として2CPUランナーの1/3な価格です。

  • ubuntu-slim: $0.002/min (2025年: $0.002/min)
  • ubuntu-24.04: $0.006/min (2025年: $0.008/min)
  • ubuntu-24.04-4core: $0.012/min (2025年: $0.016/min)

切り替え方も簡単です。これまで、ubuntu-24.04ubuntu-latestを指定していたところを、ubuntu-slimに変えるだけです。

jobs:
  lint:
    runs-on: ubuntu-slim # ここを変更
    timeout-minutes: 15 # slimは最長15分まで
    steps:
      - ...

切り替えは、LLMに適当にお願いするのもいいでしょう。

.github/workflowsに配置されているGitHub Actionsワークフローファイルを分析して、ubuntu-slimに切り替え可能なジョブを特定し、切り替えてください。

切り替え条件:
- Dockerを使用していない
- 実行時間が15分以内に収まりそう
- 軽量なlint、テスト、自動化タスクなど、CPU集約的ではないビルド処理を対象とする

切り替え時の変更:
- runs-onをubuntu-slimに変更
- timeout-minutesを15以下に設定(未設定の場合は適切な値を追加)

切り替えできないジョブについては、理由をコメントで説明してください。

以下も考慮してください:

- 既存の実行時間が分かる場合は、15分制限を超えないか確認
- timeout-minutesは余裕を持って設定(実行時間の1.5倍程度)
- プリインストールツール一覧: https://github.com/actions/runner-images/blob/main/images/ubuntu-slim/ubuntu-slim-Readme.md
- npmとpipは利用可能、dockerとcmakeは利用不可

ubuntu-slimが向いているケース

ubuntu-slimには、最小限のツールセットがインストールされています。インストールされている一覧は、actions/runner-imagesのREADMEで公開されているので確認してください。npmやpipは入っていますが、cmake/clangやdockerは入っていません。

このため、ubuntu-slimは次のようなケースに向いています。

  • IssueやPRの自動ラベル
  • lint/format
  • 軽量なビルド
  • ghコマンドをサクッと実行
  • actions-timelineのような軽量処理
  • 疎通確認のような待機するだけの処理

自動ラベル

actions/labelerを使うと、任意のパスにおける変更に応じて自動的にPRラベル付与できます。

name: "Pull Request Labeler"
on:
  pull_request:
    branches:
      - main

jobs:
  labeler:
    permissions:
      contents: read
      pull-requests: write
    runs-on: ubuntu-slim
    steps:
    - uses: actions/labeler@v6

lint

lint系も、ubuntu-slimで十分です。例えば、github/super-linterでもいいですし、npmやtextlintなどもいいでしょう。

name: Lint

on:
  pull_request:
    branches:
      - main

permissions: {}

jobs:
  lint:
    permissions:
      contents: read
      packages: read
      # To report GitHub Actions status checks
      statuses: write
    runs-on: ubuntu-slim
    timeout-minutes: 5
    steps:
      - name: Checkout code
        uses: actions/checkout@v6
        with:
          # super-linter needs the full git history to get the
          # list of files that changed across commits
          fetch-depth: 0
          persist-credentials: false
      - name: Super-linter
        uses: super-linter/super-linter@v8.3.2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

ghコマンド

ghコマンドをActionsで利用する機会は多く、軽量な処理が多いのでubuntu-slimで十分です。私は意識的に多用しています。

jobs:
  create-pr:
    permissions:
      contents: read
      pull-requests: write
    runs-on: ubuntu-slim
    timeout-minutes: 5
    steps:
      - uses: actions/checkout@v6
      - name: Create Pull Request
        run: |
          gh pr create --title "My PR" --body "This is my pull request." --base main --head feature-branch
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

actions-timeline

actions-timelineは、ワークフローにおける実行履歴をタイムライン風にしてSTEP_SUMMARYへ出力するアクションです。ジョブごとに仕込むのではなく、最後にまとめて実行する場合ubuntu-slimで十分です。

jobs:
  build-1:
  build-2:
  build-3:

  actions-timeline:
    needs: [build-1, build-2, build-3]
    runs-on: ubuntu-slim
    steps:
      - uses: Kesin11/actions-timeline@v2

ポーリングする処理

例えば、デプロイ時にDNSが解決できるようになったか確認したり、curlでエンドポイントを確認することがあります。こういった処理は待機が長く軽量なのでubuntu-slimで十分です。待機してるだけでお金かかるの、地味に嫌ですからね。

jobs:
  post-deploy:
    runs-on: ubuntu-slim
    timeout-minutes: 10
    steps:
      - name: Wait for DNS
        run: |
          for i in {1..10}; do
            if nslookup myservice.example.com; then
              echo "DNS resolved!"
              exit 0
            else
              echo "Waiting for DNS..."
              sleep 10
            fi
          done
          echo "DNS did not resolve in time."
          exit 1
      - name: Check Endpoint
        run: |
          for i in {1..10}; do
            if curl -sSf https://myservice.example.com/health; then
              echo "Endpoint is healthy!"
              exit 0
            else
              echo "Waiting for endpoint..."
              sleep 10
            fi
          done
          echo "Endpoint did not become healthy in time."
          exit 1

ubuntu-slimが向いていないケース

ubuntu-slimの特性から逆算すると、以下は向いていない処理です。

  • CPU複数コアを使うビルド
  • Dockerを使っている処理は移行できない
  • ランナープリインストールを前提として追加インストールしたくない処理

例えば、dotnetビルドやgoビルドはCPU複数コアを使うので軽量なプロジェクトじゃないなら向いていないでしょう。docker buildなどコンテナイメージを作成して、レジストリにプッシュする処理も向いていません。

Unityビルドも全然無理です。悲しい。

まとめ

プロジェクトにもよりますが、意外と多くのジョブは軽量な処理です。今回例に挙げたようなジョブはubuntu-slimに切り替えることで、コスト削減につながります。一個一個のコストは小さいですが、1年単位でみるとチリも積もればです。私のプロジェクトだと、20%程度のコスト削減になりました。

幸い、runs-onを変えるだけで切り替えられるので、まずは影響の小さいジョブから試しに切り替えてみてはいかがでしょうか。Dockerを使っていないなら案外いけます。あと、多少実行時間が伸びるので、実行時間が15分以内に収まるか事前に確認しておくと安心です。

参考

他の事例


  1. LLMに適当に聞いてGPUうんぬんの非対称性は、という気もしますが気にしてはいけません。
  2. パブリックリポジトリでは、CPU4コア、メモリ14GBのx64マシンになります。