はじめに
実際の CI/CD パイプラインでは、ワークフローが単一のステップリストであることは稀です。多くの場合、特定の順序で実行する必要がある複数の明確な「ジョブ (job)」で構成されています。
例えば、コードをコンパイルする Build ジョブと、サーバーにプッシュする Deploy ジョブがあるかもしれません。Build ジョブが失敗した場合に Deploy ジョブを実行したくありませんし、デプロイにはビルドされた成果物が必要なため、同時に実行することもできません。
この実験 (Lab) では、ワークフローを 2 つの別々のジョブに分割し、needs キーワードを使用して依存関係を強制し、デプロイジョブがビルドジョブの正常な完了を待機するようにします。
この実験 (Lab) は、以前の実験 (Lab) で作成したリポジトリに基づいています。github-actions-demo リポジトリを使用します。
ビルドジョブの定義
まず、既存のワークフローを整理し、焦点を絞った build ジョブを作成します。明確化のため、前の実験(Lab)で用いたマトリックス戦略を簡略化し、ジョブ依存関係に焦点を当てるために単一バージョンに戻します。
github-actions-demoの GitHub リポジトリページで、緑色の Code ボタンをクリックします。- HTTPS タブが選択されていることを確認し、URL をコピーします。URL は
https://github.com/your-username/github-actions-demo.gitのようになるはずです。 - LabEx 環境でターミナルを開きます。デフォルトのパスは
~/projectです。 git cloneコマンドを使用してリポジトリをダウンロードします。your-usernameはご自身の GitHub ユーザー名に置き換えてください。
cd ~/project
git clone https://github.com/your-username/github-actions-demo.git
出力例:
Cloning into 'github-actions-demo'...
remote: Enumerating objects: X, done.
remote: Counting objects: 100% (X/X), done.
remote: Total X (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (X/X), done.
- クローンしたリポジトリに移動します。
cd ~/project/github-actions-demo
WebIDE エディタを使用して、新しいワークフローファイル
.github/workflows/job-dependencies.ymlを作成します。ファイルエクスプローラーの左側にあるproject/github-actions-demo/.github/workflows/の下でファイルを見つけることができます。基本的なワークフロー構造の作成から始めます。ワークフロー名とトリガーを追加します。
name: Job Dependencies
on: [push]
jobsセクションを追加し、ランナーを指定してbuildジョブを定義します。
jobs:
build:
runs-on: ubuntu-latest
stepsセクションを追加します。まず、リポジトリコードを取得するための checkout ステップを追加します。
steps:
- uses: actions/checkout@v4
- Node.js セットアップステップを追加します。
- name: Use Node.js
uses: actions/setup-node@v4
with:
node-version: "20"
- 依存関係をインストールするステップを追加します。
- name: Install dependencies
run: npm install
- テストを実行するステップを追加します。
- name: Run tests
run: npm test
- アーティファクトディレクトリとファイルを作成するビルドステップを追加します。
- name: Build project
run: |
mkdir dist
echo "Build artifact created at $(date)" > dist/build.txt
- 最後に、アーティファクトをアップロードするステップを追加します。このステップは、次のジョブがビルド出力を利用できるようにするために不可欠です。
- name: Upload build artifact
uses: actions/upload-artifact@v4
with:
name: dist-files
path: dist
完成したファイルは次のようになります。
name: Job Dependencies
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Use Node.js
uses: actions/setup-node@v4
with:
node-version: "20"
- name: Install dependencies
run: npm install
- name: Run tests
run: npm test
- name: Build project
run: |
mkdir dist
echo "Build artifact created at $(date)" > dist/build.txt
- name: Upload build artifact
uses: actions/upload-artifact@v4
with:
name: dist-files
path: dist
解説
- 簡略化のため、
matrix戦略を削除しました。 Upload build artifactステップは保持しました。これは、次のジョブがこれらのファイル(成果物)を必要とするため、極めて重要です!
変更を加えたら、ファイルを保存してください (Ctrl+S または Cmd+S)。
ビルドに依存するデプロイジョブの定義
次に、deploy という名前の 2 番目のジョブを追加します。このジョブは build が成功した場合にのみ実行されるようにします。これには needs: build を使用します。
.github/workflows/job-dependencies.ymlファイルに、以下のdeployジョブを追記します。buildジョブと同じインデントレベルにあることを確認してください。まず、ランナーと依存関係を指定してデプロイジョブの定義を追加します。
deploy:
runs-on: ubuntu-latest
needs: build
needs: build の行は極めて重要です。これは、GitHub Actions に対して、このジョブが build ジョブの正常な完了に依存していることを伝えます。
- ステップセクションを追加します。まず、アーティファクトをダウンロードするステップを追加します。
steps:
- name: Download artifact
uses: actions/download-artifact@v4
with:
name: dist-files
path: dist
これにより、build ジョブでアップロードされたアーティファクトがダウンロードされます。name はアップロードステップで使用された名前と一致している必要があります。
- デプロイステップを追加します。
- name: Deploy project
run: |
echo "Deploying project..."
ls -R dist
echo "Deployment successful!"
このステップは、ダウンロードしたファイルを一覧表示することでデプロイをシミュレートします。
- 完全なファイル構造は次のようになります。
name: Job Dependencies
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Use Node.js
uses: actions/setup-node@v4
with:
node-version: "20"
- name: Install dependencies
run: npm install
- name: Run tests
run: npm test
- name: Build project
run: |
mkdir dist
echo "Build artifact created at $(date)" > dist/build.txt
- name: Upload build artifact
uses: actions/upload-artifact@v4
with:
name: dist-files
path: dist
deploy:
runs-on: ubuntu-latest
needs: build
steps:
- name: Download artifact
uses: actions/download-artifact@v4
with:
name: dist-files
path: dist
- name: Deploy project
run: |
echo "Deploying project..."
ls -R dist
echo "Deployment successful!"
解説
needs: build: これが鍵となる行です。このジョブがbuildジョブの正常な完了に依存していることを GitHub Actions に伝えます。uses: actions/download-artifact@v4: ジョブは異なる仮想マシン上で実行されるため、ファイルシステムを共有しません。buildジョブで作成されたdistフォルダを取得するには、以前にアップロードしたアーティファクトをダウンロードする必要があります。name: dist-files: アップロードステップで使用された名前と一致している必要があります。
ファイルを保存します (Ctrl+S または Cmd+S)。
コミット、プッシュ、および逐次実行の検証
これで、ジョブが正しい順序で実行されることを確認しましょう。
- リポジトリのディレクトリにいることを確認します。
cd ~/project/github-actions-demo
- 変更をステージングします。
git add .
- 変更をコミットします。
git commit -m "Add deploy job with dependency on build"
- 変更を GitHub 上のリモートリポジトリにプッシュします。
git push
認証に関する注意:
git push を実行すると、WebIDE は自動的に認証を求めます。以下の詳細な手順に従ってください。
- "The extension 'GitHub' wants to sign in using GitHub." というメッセージが表示されたポップアップが表示されます。「Allow」をクリックします。
- 新しい通知が表示されます。「Copy&Continue to GitHub」をクリックし、次のプロンプトで「Open」をクリックします。
- 開いたブラウザウィンドウで GitHub アカウントにログインし、コピーされた認証コードを入力します。認証を確認した後、ページは自動的に閉じます。
- 数秒待つと、ターミナルでプッシュ操作が正常に完了したことが確認できます。
プライバシーに関する注意: WebIDE は認証目的で GitHub アカウントへのフルアクセスを要求します。プライバシーに関する懸念は不要です。現在の実験(Lab)が完了すると、LabEx VM は直ちに破棄され、認証情報や認可情報は保持されません。
この認証プロセスでは、ユーザー名や Personal Access Token を手動で設定する必要はありません。
GitHub での確認
- Web ブラウザで GitHub 上のリポジトリにアクセスします。
- Actions タブをクリックします。
- 最新のワークフロー実行をクリックします。
- 視覚化グラフを確認します。線で結ばれた 2 つの円(ジョブ)が見えるはずです。
buildジョブが左側にあります。deployジョブが右側にあります。
- 進捗を監視します。
buildが緑色(Success)になるまで、deployが「Pending」または「Waiting」状態のままであることに気づくでしょう。 buildが完了すると、deployが開始されます。deployジョブのログをクリックして、「Deploying project...」メッセージと、ダウンロードされたアーティファクトのファイル一覧を確認します。

まとめ
この実験 (Lab) では、GitHub Actions でマルチジョブワークフローをオーケストレーションする方法を学びました。以下のことを行いました。
- 個別の
buildジョブとdeployジョブを作成しました。 needsキーワードを使用して依存関係を定義し、deployがbuildの後にのみ実行されるようにしました。upload-artifactおよびdownload-artifactを使用して、これらの個別のジョブ間でデータ(ファイル)を渡しました。
このパターンは、一度ビルドし、前のステップが成功した場合にのみ複数の環境(ステージング、本番環境など)にデプロイしたい、堅牢な CI/CD パイプラインを構築するための基本となります。



