Railwayはこちら

GitHub Actionsセルフホストランナー

このチュートリアルでは、Railway上に独自の、スケーラブルなGitHub Actionsセルフホストランナーフリートをデプロイする方法を説明します。これにより、CI/CDのビルド時間を大幅に短縮し、コストを最適化できます。

RailwayにGitHubセルフホストランナーをデプロイする

Railwayのテンプレートを使用して、GitHub Actionsランナーをワンクリックでデプロイできます。

GitHub ACCESS_TOKENの設定

ランナーがリポジトリに登録されるためには、適切な権限を持つGitHubパーソナルアクセストークン（PAT）が必要です。このトークンをRailwayサービスの環境変数 GITHUB_ACCESS_TOKEN として設定します。

Railwayセルフホストランナーのスケーリング

サービスのレプリカ数を増やすことで、ランナーの数を簡単にスケールアップできます。これにより、複数のジョブを並行して実行できるようになり、ビルドの待ち時間が短縮されます。

登録されたセルフホストランナーの表示

GitHubリポジトリの Settings > Actions > Runners で、Railwayから登録されたランナーを確認できます。

Actionsジョブのルーティング

ワークフローファイル（.github/workflows/main.ymlなど）で、runs-onキーをself-hostedに設定することで、ジョブがセルフホストランナーで実行されるように指定します。

プルリクエスト用のGitHub Actionsワークフローの設定

プルリクエストが開かれたときにCIが実行されるように、ワークフローのトリガーを設定します。

GitHub Actionsワークフローの例

name: CI

on:
  pull_request:

jobs:
  build:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v3
      - name: Build and Test
        run: |
          npm install
          npm test

ベストプラクティス

• セキュリティ: secretsを使用して、アクセストークンなどの機密情報を安全に管理します。
• コスト管理: 使用しないときはランナーサービスのレプリカ数を0にスケールダウンするなどして、コストを最適化します。
• ランナーの分離: 異なるリポジトリや組織のために、別々のランナーサービスをデプロイすることを検討してください。

既知の制限

• Railwayの一時的なファイルシステムのため、ビルド間のキャッシュは永続化されません。

セルフホストランナー通信のトラブルシューティング

• GitHubのアクセストークンが正しい権限を持っていることを確認してください。
• Railwayサービスのログで、ランナーの登録やジョブの取得に関するエラーがないか確認してください。

コスト比較

GitHubホストランナーと比較して、Railwayのセルフホストランナーは、特にビルド時間が長い場合や並列実行が多い場合に、大幅なコスト削減につながる可能性があります。

Railwayはこちら