Note
GitHub ホステッド ランナーは、現在 GitHub Enterprise Server ではサポートされていません。 GitHub public roadmap で、今後の計画的なサポートの詳細を確認できます。
変数について
変数は、機密性の低い構成情報を格納して再利用する方法を提供します。 コンパイラ フラグ、ユーザー名、サーバー名などの任意の構成データを変数として格納できます。 変数は、ワークフローを実行するランナー マシンで補間されます。 アクションまたはワークフロー ステップ内で実行されるコマンドで、変数の作成、読み取り、変更ができます。
独自のカスタム変数を設定することも、GitHub が自動的に設定する既定の環境変数を使用することもできます。 詳しくは、「既定の環境変数」をご覧ください。
カスタム変数は、2 つの方法で設定できます。
- 1 つのワークフローで使用する環境変数を定義する場合、ワークフロー ファイルで
env
キーを使用できます。 詳しくは、「単一のワークフローの環境変数の定義」をご覧ください。 - 複数のワークフローにわたって構成変数を定義する場合、Organization、リポジトリ、または環境レベルで定義できます。 詳しくは、「複数のワークフローに対する構成変数の定義」をご覧ください。
Warning
既定では、変数は、ビルド出力にマスクされていない状態でレンダリングされます。 パスワードなどの機密情報のセキュリティを強化する必要がある場合は、代わりにシークレットを使用してください。 詳しくは、「GitHub Actions でのシークレットの使用」をご覧ください。
単一のワークフローの環境変数の定義
単一のワークフローにカスタム環境変数を設定するには、ワークフロー ファイル内の env
キーを使用して環境変数を定義できます。 このメソッドで設定されるカスタム変数のスコープは、定義されている要素に制限されます。 次のスコープを設定する変数を定義できます。
- ワークフロー全体 (ワークフロー ファイルの最上位レベルで
env
を使用)。 - ワークフロー内のジョブの内容 (
jobs.<job_id>.env
を使用)。 - ジョブ内の特定の手順 (
jobs.<job_id>.steps[*].env
を使用)。
name: Greeting on variable day on: workflow_dispatch env: DAY_OF_WEEK: Monday jobs: greeting_job: runs-on: ubuntu-latest env: Greeting: Hello steps: - name: "Say Hello Mona it's Monday" run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!" env: First_Name: Mona
name: Greeting on variable day
on:
workflow_dispatch
env:
DAY_OF_WEEK: Monday
jobs:
greeting_job:
runs-on: ubuntu-latest
env:
Greeting: Hello
steps:
- name: "Say Hello Mona it's Monday"
run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!"
env:
First_Name: Mona
env
変数の値には、ランナー環境変数またはコンテキストを使用してアクセスできます。 上の例は、echo
コマンド ($DAY_OF_WEEK
、$Greeting
、$First_Name
) でランナー環境変数として使用されている 3 つのカスタム変数を示しています。 これらの変数の値は、それぞれワークフロー、ジョブ、ステップ レベルで設定され、スコープも設定されます。 これらの変数の補間はランナーで行われます。
ワークフローの run
ステップまたは参照されるアクションのコマンドは、ランナーで使用しているシェルによって処理されます。 ワークフローの一部は GitHub Actions によって処理され、ランナーには送信されません。 run
ステップでは、ランナー環境変数またはコンテキストのいずれかを使用できますが、ランナーに送信されないワークフローの部分では、変数値にアクセスするためにコンテキストを使用する必要があります。 詳しくは、「コンテキストを使用した変数の値へのアクセス」をご覧ください。
ランナー環境変数の補間は、ワークフロー ジョブがランナー マシンに送信された後に行われるため、ランナーで使用されるシェルに適切な構文を使用する必要があります。 この例では、ワークフローは ubuntu-latest
を指定します。 既定では、Linux ランナーは Bash シェルを使用するため、構文 $NAME
を使用する必要があります。 既定では、Windows ランナーは PowerShell を使用するため、構文 $env:NAME
を使用します。 シェルについて詳しくは、「GitHub Actions のワークフロー構文」をご覧ください。
環境変数の命名規則
環境変数を設定する場合、既定の環境変数名は使用できません。 既定の環境変数の完全な一覧については、以下の「既定の環境変数」をご覧ください。 これらの既定の変数のいずれかの値をオーバーライドしようとすると、割り当ては無視されます。
Note
ステップで run: env
を使用して、ワークフロー ステップで使用できる環境変数のセット全体を一覧表示し、そのステップの出力を調べることができます。
複数のワークフローに対する構成変数の定義
複数のワークフローにわたって使用する構成変数を作成し、Organization、リポジトリ、または環境レベルでそれらを定義できます。
たとえば、構成変数を使用して、Organization レベルでツールを構築するために渡されるパラメーターの既定値を設定しながら、リポジトリ所有者がケースバイケースでこれらのパラメーターをオーバーライドできるようにします。
構成変数を定義すると、vars
コンテキストで自動的に使用できるようになります。 詳しくは、「vars
コンテキストを使用した構成変数の値へのアクセス」をご覧ください。
構成変数の優先順位
複数のレベルで同じ名前の変数が存在する場合、最も低いレベルの変数が優先されます。 たとえば、Organization レベルの変数名がリポジトリレベルの変数名と同じ場合、リポジトリレベルの変数が優先されます。 同様に、Organization、リポジトリ、環境がすべて同じ名前の変数を持つ場合、環境レベルの変数が優先されます。
再利用可能なワークフローの場合は、呼び出し元ワークフローのリポジトリの変数が使用されます。 呼び出されたワークフローを含むリポジトリの変数は、呼び出し元ワークフローでは使用できません。
構成変数の名前付け規則
構成変数名には次の規則が適用されます。
- 名前には英数字 (
[a-z]
、[A-Z]
、[0-9]
) またはアンダースコア (_
) のみを含めることができます。 スペースは使用できません。 - 名前の最初を
GITHUB_
プレフィックスにすることはできません。 - 名前の最初を数字にすることはできません。
- 名前では大文字と小文字は区別されません。
- 名前は、作成されたレベルで一意である必要があります。
リポジトリの構成変数の作成
GitHub 上で個人用アカウント リポジトリのシークレットまたは変数を作成するユーザーは、リポジトリのオーナーである必要があります。 GitHub 上で組織用リポジトリのシークレットまたは変数を作成するユーザーは、admin
アクセス権を持っている必要があります。 最後に、個人用アカウント リポジトリまたは組織用リポジトリのシークレットまたは変数を REST API 経由で作成するユーザーには、コラボレーター アクセス権が必要です。
-
GitHub で、リポジトリのメイン ページに移動します。
-
リポジトリ名の下にある [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。
-
サイドバーの [セキュリティ] セクションで、 [ シークレットと変数] を選択し、次に [アクション] をクリックします。
-
[変数] タブをクリックします。
-
[新しいリポジトリ変数] をクリックします。
-
[名前] フィールドに、変数の名前を入力します。
-
[値] フィールドに、変数の値を入力します。
-
[変数の追加] をクリックします。
環境の構成変数の作成
個人用アカウントのリポジトリ内の環境でシークレットか変数を作成するユーザーは、そのリポジトリのオーナーである必要があります。 組織用リポジトリ内の環境用にシークレットか変数を作成するユーザーには、admin
のアクセス権が必要です。 環境について詳しくは、「デプロイに環境の使用」を参照してください。
-
GitHub で、リポジトリのメイン ページに移動します。
-
リポジトリ名の下にある [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。
-
左側のサイドバーで、 [環境] をクリックします。
-
変数を追加したい環境をクリックしてください。
-
[環境変数] で [変数の追加] をクリックします。
-
[名前] フィールドに、変数の名前を入力します。
-
[値] フィールドに、変数の値を入力します。
-
[変数の追加] をクリックします。
Organization の構成変数の作成
Organization でシークレットまたは変数を作成する場合、ポリシーを使用して、リポジトリによるアクセスを制限できます。 たとえば、すべてのリポジトリにアクセスを許可したり、プライベート リポジトリまたは指定したリポジトリ のリストのみにアクセスを制限したりできます。
Organization のオーナーは、Organization レベルでシークレットまたは変数を作成できます。
-
GitHub で、organization のメイン ページに移動します。
-
組織名の下で、 [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。
-
サイドバーの [セキュリティ] セクションで、 [ シークレットと変数] を選択し、次に [アクション] をクリックします。
-
[変数] タブをクリックします。
-
[新しい Organization 変数] をクリックします。
-
[名前] フィールドに、変数の名前を入力します。
-
[値] フィールドに、変数の値を入力します。
-
[リポジトリアクセス] ドロップダウンリストから、アクセスポリシーを選びます。
-
[変数の追加] をクリックします。
構成変数の制限
個々の変数のサイズは最大 48 KB です。
最大で 1,000 個の組織変数、リポジトリあたり 500 個の変数、および環境あたり 100 個の変数を格納できます。 組織変数とリポジトリ変数の合計サイズの上限は、ワークフローの実行あたり 10 MB です。
リポジトリに作成されたワークフローは、次の数の変数にアクセスできます。
- リポジトリ変数の合計サイズが 10 MB 未満の場合、リポジトリ変数は最大 500 個です。 リポジトリ変数の合計サイズが 10 MB を超える場合、(変数名でアルファベット順に並べ替えをして) 制限を超えないリポジトリ変数のみが使用できます。
- リポジトリ変数と組織変数の合計サイズが 10 MB 未満の場合、組織変数は最大 1,000 個です。 組織変数とリポジトリ変数の合計サイズが 10 MB を超える場合は、(リポジトリ変数を処理した後、変数名でアルファベット順に並べ替えをして) その制限を超えない組織変数のみが使用できます。
- 最大 100 個の環境レベル変数。
Note
環境レベル変数は、合計 10 MB のサイズ制限にはカウントされません。 リポジトリ変数と組織変数の合計サイズ制限を超えた場合でも、追加の変数が必要な場合は、環境を使い、その環境で追加の変数を定義できます。
コンテキストを使用した変数の値へのアクセス
コンテキストは、ワークフローの実行、変数、ランナーの環境、ジョブ、ステップに関する情報にアクセスする方法です。詳しくは、「ワークフロー実行に関するコンテキスト情報へのアクセス」をご覧ください。 ワークフローには、さまざまな目的で使用できる他の多くのコンテキストがあります。 ワークフロー内で特定のコンテキストを使用できる場所について詳しくは、「ワークフロー実行に関するコンテキスト情報へのアクセス」をご覧ください。
env
コンテキストを使用して環境変数値にアクセスし、vars
コンテキストを使用して構成変数値にアクセスできます。
env
コンテキストを使用した環境変数の値へのアクセス
GitHub Actions では、ランナー環境変数に加えて、コンテキストを使用した env
キー値の設定および読み取りを行うことができます。 環境変数やコンテキストは、ワークフロー中の様々な場所で利用できます。
ワークフローまたは参照先アクションの run
ステップは、ランナーによって処理されます。 その結果、ランナーで使用するシェル (Linux ランナーの bash シェル用の $NAME
や Windows ランナーの PowerShell用の $env:NAME
など) に適した構文を使用して、ランナー環境変数をここで使用できます。 ほとんどの場合、コンテキストと構文 ${{ CONTEXT.PROPERTY }}
を使用して、同じ値にアクセスすることもできます。 違いは、ジョブがランナーに送信される前にコンテキストが補間され、文字列に置き換えられるということです。
ただし、GitHub Actions によって処理され、ランナーには送信されないワークフローの一部のランナー環境変数値は使用できません。 その代わりに、コンテキストを使用することができます。 たとえば、ジョブまたはステップがランナーに送信されるかどうかを決定する if
条件は、常に GitHub Actions によって処理されます。 if
条件付きステートメントでコンテキストを使用して、変数の値にアクセスする必要があります。
name: Conditional env variable on: workflow_dispatch env: DAY_OF_WEEK: Monday jobs: greeting_job: runs-on: ubuntu-latest env: Greeting: Hello steps: - name: "Say Hello Mona it's Monday" if: ${{ env.DAY_OF_WEEK == 'Monday' }} run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!" env: First_Name: Mona
name: Conditional env variable
on: workflow_dispatch
env:
DAY_OF_WEEK: Monday
jobs:
greeting_job:
runs-on: ubuntu-latest
env:
Greeting: Hello
steps:
- name: "Say Hello Mona it's Monday"
if: ${{ env.DAY_OF_WEEK == 'Monday' }}
run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!"
env:
First_Name: Mona
前の例のこの変更では、if
条件を導入しました。 ワークフロー ステップは、DAY_OF_WEEK
が "Monday" に設定されている場合にのみ実行されます。 env
コンテキストを使用して、if
条件付きステートメントからこの値にアクセスします。 run
コマンド内で参照される変数には、 env
コンテキストは必要ありません。 これらはランナー環境変数として参照され、ランナーがジョブを受信した後に補間されます。 ただし、コンテキストを使用して、ランナーにジョブを送信する前に、これらの変数を補間することを選択できました。 結果の出力は同じになります。
run: echo "${{ env.Greeting }} ${{ env.First_Name }}. Today is ${{ env.DAY_OF_WEEK }}!"
Note
コンテキストは通常、${{ context.property }}
としてドル記号と中かっこを使用して示されます。 if
条件では、${{
と }}
は省略可能ですが、それらを使用する場合は、上記のように比較ステートメント全体を囲む必要があります。
ジョブがランナーに送信される前に処理されるワークフローの一部で、変数の値にアクセスするには、通常 env
または github
コンテキストを使用します。
Context | 使用事例 | 例 |
---|---|---|
env | ワークフローで定義されているカスタム変数を参照します。 | ${{ env.MY_VARIABLE }} |
github | ワークフローの実行とその実行をトリガーしたイベントの情報を参照します。 | ${{ github.repository }} |
Warning
ワークフローとアクションを作成するときは、攻撃者によってコードが信頼されていない入力を実行する可能性があるかどうかを常に考慮する必要があります。 攻撃者が悪意あるコンテンツを挿入してくるかもしれないので、特定のコンテキストは信頼できない入力として扱うべきです。 詳しくは、「GitHub Actions のセキュリティ強化」を参照してください。
vars
コンテキストを使用した構成変数の値へのアクセス
構成変数には、vars
コンテキストを使用してワークフロー全体でアクセスできます。 詳しくは、「ワークフロー実行に関するコンテキスト情報へのアクセス」をご覧ください。
構成変数が設定されていない場合、変数を参照するコンテキストの戻り値は空の文字列になります。
次の例は、ワークフロー全体で vars
コンテキストと共に構成変数を使用する方法を示しています。 次の各構成変数は、リポジトリ、Organization、または環境レベルで定義されています。
on: workflow_dispatch: env: # Setting an environment variable with the value of a configuration variable env_var: ${{ vars.ENV_CONTEXT_VAR }} jobs: display-variables: name: ${{ vars.JOB_NAME }} # You can use configuration variables with the `vars` context for dynamic jobs if: ${{ vars.USE_VARIABLES == 'true' }} runs-on: ${{ vars.RUNNER }} environment: ${{ vars.ENVIRONMENT_STAGE }} steps: - name: Use variables run: | echo "repository variable : $REPOSITORY_VAR" echo "organization variable : $ORGANIZATION_VAR" echo "overridden variable : $OVERRIDE_VAR" echo "variable from shell environment : $env_var" env: REPOSITORY_VAR: ${{ vars.REPOSITORY_VAR }} ORGANIZATION_VAR: ${{ vars.ORGANIZATION_VAR }} OVERRIDE_VAR: ${{ vars.OVERRIDE_VAR }} - name: ${{ vars.HELLO_WORLD_STEP }} if: ${{ vars.HELLO_WORLD_ENABLED == 'true' }} uses: actions/hello-world-javascript-action@main with: who-to-greet: ${{ vars.GREET_NAME }}
on:
workflow_dispatch:
env:
# Setting an environment variable with the value of a configuration variable
env_var: ${{ vars.ENV_CONTEXT_VAR }}
jobs:
display-variables:
name: ${{ vars.JOB_NAME }}
# You can use configuration variables with the `vars` context for dynamic jobs
if: ${{ vars.USE_VARIABLES == 'true' }}
runs-on: ${{ vars.RUNNER }}
environment: ${{ vars.ENVIRONMENT_STAGE }}
steps:
- name: Use variables
run: |
echo "repository variable : $REPOSITORY_VAR"
echo "organization variable : $ORGANIZATION_VAR"
echo "overridden variable : $OVERRIDE_VAR"
echo "variable from shell environment : $env_var"
env:
REPOSITORY_VAR: ${{ vars.REPOSITORY_VAR }}
ORGANIZATION_VAR: ${{ vars.ORGANIZATION_VAR }}
OVERRIDE_VAR: ${{ vars.OVERRIDE_VAR }}
- name: ${{ vars.HELLO_WORLD_STEP }}
if: ${{ vars.HELLO_WORLD_ENABLED == 'true' }}
uses: actions/hello-world-javascript-action@main
with:
who-to-greet: ${{ vars.GREET_NAME }}
既定の環境変数
GitHub が設定する既定の環境変数は、ワークフローのどのステップでも使用できます。
既定の環境変数は GitHub によって設定され、ワークフローで定義されていないため、env
コンテキストを介してアクセスすることはできません。 しかし、既定の変数のほとんどは、対応する、似た名前のコンテキスト プロパティを持ちます。 たとえば、${{ github.ref }}
コンテキスト プロパティを使用してワークフロー処理中に GITHUB_REF
変数の値を読み取ることができます。
GITHUB_*
および RUNNER_*
という名前の既定の環境変数の値を上書きすることはできません。 現時点では、CI
変数の値を上書きできます。 ただし、これが常に可能になることは保証されていません。環境変数の設定について詳しくは、「単一のワークフローの環境変数の定義」と「GitHub Actions のワークフロー コマンド」をご覧ください。
アクションでは、ファイルシステムにアクセスするとき、ハードコードされたファイル パスを使うのではなく変数を使用することを強くお勧めします。 GitHub は、すべてのランナー環境でアクションが使用する変数を設定します。
変数 | 説明 |
---|---|
CI | 常に true に設定します。 |
GITHUB_ACTION | 現在実行中のアクションの名前、またはステップの id 。 たとえば、アクションの場合は __repo-owner_name-of-action-repo 。GitHub では特殊文字を削除し、現在のステップで id なしでスクリプトを実行するときに __run という名前を使用します。 同じジョブで同じスクリプトまたはアクションを複数回使用する場合、名前には、アンダースコアとシーケンス番号から成るサフィックスが含まれます。 たとえば、実行する最初のスクリプトの名前は __run で、2 番目のスクリプトの名前は __run_2 となります。 同様に、actions/checkout の 2 番目の呼び出しは actionscheckout2 になります。 |
GITHUB_ACTION_PATH | アクションが置かれているパス。 このプロパティは、複合アクションでのみサポートされます。 このパスを使用して、処置が同じリポジトリにあり、その他ファイルにアクセスできるディレクトリを変更できます。 たとえば、/home/runner/work/_actions/repo-owner/name-of-action-repo/v1 のようにします。 |
GITHUB_ACTION_REPOSITORY | アクションを実行するステップの場合、これはアクションの所有者とリポジトリの名前です。 たとえば、actions/checkout のようにします。 |
GITHUB_ACTIONS | GitHub Actions がワークフローを実行しているときは常に true に設定されます。 この変数は、テストがローカルで実行されているときと、GitHub Actionsによって実行されているときを区別するために利用できます。 |
GITHUB_ACTOR | ワークフローを開始するユーザまたはアプリの名前。 たとえば、octocat のようにします。 |
GITHUB_ACTOR_ID | 最初のワークフロー実行をトリガーしたユーザーまたはアプリのアカウント ID。 たとえば、1234567 のようにします。 これはアクターのユーザー名とは異なることに注意してください。 |
GITHUB_API_URL | API URL を返します。 (例: http(s)://HOSTNAME/api/v3 )。 |
GITHUB_BASE_REF | ワークフローの実行における base ref の名前または pull request のターゲット ブランチ。 これは、ワークフローの実行をトリガーするイベントが pull_request か pull_request_target である場合にのみ設定されます。 たとえば、main のようにします。 |
GITHUB_ENV | ワークフロー コマンドから変数を設定するファイルへのランナーのパス。 このファイルへのパスは現在のステップに固有であり、ジョブのステップごとに変更されます。 たとえば、/home/runner/work/_temp/_runner_file_commands/set_env_87406d6e-4979-4d42-98e1-3dab1f48b13a のようにします。 詳しくは、「GitHub Actions のワークフロー コマンド」をご覧ください。 |
GITHUB_EVENT_NAME | ワークフローをトリガーしたイベントの名前。 たとえば、workflow_dispatch のようにします。 |
GITHUB_EVENT_PATH | 完全なイベント Webhook ペイロードを含むランナー上のファイルへのパス。 たとえば、/github/workflow/event.json のようにします。 |
GITHUB_GRAPHQL_URL | グラフ QL API の URL を返します。 (例: http(s)://HOSTNAME/api/graphql )。 |
GITHUB_HEAD_REF | ワークフローの実行における head ref または pull request のソース ブランチ。 このプロパティは、ワークフローの実行をトリガーするイベントが pull_request か pull_request_target である場合にのみ設定されます。 たとえば、feature-branch-1 のようにします。 |
GITHUB_JOB | 現在のジョブの job_id。 たとえば、greeting_job のようにします。 |
GITHUB_OUTPUT | ワークフロー コマンドからの現在のステップの出力を設定するファイルへのランナー上のパス。 このファイルへのパスは現在のステップに固有であり、ジョブのステップごとに変更されます。 たとえば、/home/runner/work/_temp/_runner_file_commands/set_output_a50ef383-b063-46d9-9157-57953fc9f3f0 のようにします。 詳しくは、「GitHub Actions のワークフロー コマンド」をご覧ください。 |
GITHUB_PATH | ワークフロー コマンドから PATH システム変数を設定するファイルへのランナーのパス。 このファイルへのパスは現在のステップに固有であり、ジョブのステップごとに変更されます。 たとえば、/home/runner/work/_temp/_runner_file_commands/add_path_899b9445-ad4a-400c-aa89-249f18632cf5 のようにします。 詳しくは、「GitHub Actions のワークフロー コマンド」をご覧ください。 |
GITHUB_REF | ワークフローの実行をトリガーしたブランチまたはタグの完全な形式の参照。 push によってトリガーされるワークフローの場合、これはプッシュされたブランチまたはタグの参照です。 pull_request によってトリガーされるワークフローの場合、これは pull request のマージ ブランチです。 release によってトリガーされるワークフローの場合、これは作成されたリリース タグです。 その他のトリガーの場合、これはワークフロー実行をトリガーしたブランチまたはタグの参照です。 これは、イベントの種類に対してブランチまたはタグを使用できる場合にのみ設定されます。 指定する参照は完全な形式です。つまり、ブランチの場合の形式は refs/heads/<branch_name> 、pull request の場合は refs/pull/<pr_number>/merge 、タグの場合は refs/tags/<tag_name> です。 たとえば、「 refs/heads/feature-branch-1 」のように入力します。 |
GITHUB_REF_NAME | ワークフローの実行をトリガーしたブランチまたはタグの短い参照名。 この値は、GitHub に表示されるブランチまたはタグ名と一致します。 たとえば、feature-branch-1 のようにします。pull request の場合、形式は <pr_number>/merge 。 |
GITHUB_REF_PROTECTED | true 分岐保護が、ワークフロー実行をトリガーした ref に対して構成されている場合。 |
GITHUB_REF_TYPE | ワークフローの実行をトリガーした ref の種類。 有効な値は branch または tag です。 |
GITHUB_REPOSITORY | 所有者およびリポジトリの名前。 たとえば、octocat/Hello-World のようにします。 |
GITHUB_REPOSITORY_ID | リポジトリの ID。 たとえば、「 123456789 」のように入力します。 これはリポジトリ名とは異なることに注意してください。 |
GITHUB_REPOSITORY_OWNER | リポジトリ所有者の名前。 たとえば、octocat のようにします。 |
GITHUB_REPOSITORY_OWNER_ID | リポジトリ所有者のアカウント ID。 たとえば、「 1234567 」のように入力します。 これは所有者名とは異なることに注意してください。 |
GITHUB_RETENTION_DAYS | ワークフロー実行ログと成果物が保持される日数。 たとえば、90 のようにします。 |
GITHUB_RUN_ATTEMPT | リポジトリ内で実行される特定のワークフローの各試行に割り振られる一意の番号。 この番号は、ワークフロー実行の最初の試行時に 1 で始まり、再実行ごとに増加します。 たとえば、3 のようにします。 |
GITHUB_RUN_ID | 各ワークフローの一意の番号は、リポジトリ内で実行されます。 この番号は、ワークフローの実行をやり直しても変化しません、 たとえば、1658821493 。 |
GITHUB_RUN_NUMBER | リポジトリ内の特定のワークフローの各実行に対するユニークな番号。 この番号は、ワークフローの最初の実行時に 1 から始まり、新しい実行ごとに増加します。 この番号は、ワークフローの実行をやり直しても変化しません、 たとえば、3 。 |
GITHUB_SERVER_URL | GitHub Enterprise Server サーバーの URL。 (例: https://HOSTNAME )。 |
GITHUB_SHA | ワークフローをトリガーしたコミット SHA。 このコミット SHA の値は、ワークフローをトリガーしたイベントによって異なります。 詳しくは、「ワークフローをトリガーするイベント」を参照してください。 たとえば、「 ffac537e6cbbf934b08745a378932722df287a53 」のように入力します。 |
GITHUB_STEP_SUMMARY | ワークフロー コマンドからのジョブの概要を含むファイルへのランナー上のパス。 このファイルへのパスは現在のステップに固有であり、ジョブのステップごとに変更されます。 たとえば、/home/runner/_layout/_work/_temp/_runner_file_commands/step_summary_1cb22d7f-5663-41a8-9ffc-13472605c76c のようにします。 詳しくは、「GitHub Actions のワークフロー コマンド」をご覧ください。 |
GITHUB_TRIGGERING_ACTOR | ワークフローの実行を開始したユーザーのユーザー名。 ワークフローの実行が再実行である場合、この値は github.actor と異なることがあります。 ワークフローのすべての再実行では、再実行を開始したアクター (github.triggering_actor ) が異なる特権を持っている場合であっても、github.actor の特権が使われます。 |
GITHUB_WORKFLOW | ワークフローの名前です。 たとえば、My test workflow のようにします。 ワークフロー ファイルで name を指定していない場合、このプロパティの値は、リポジトリ内にあるワークフロー ファイルの完全なパスになります。 |
GITHUB_WORKFLOW_REF | ワークフローへの参照パス。 たとえば、「 octocat/hello-world/.github/workflows/my-workflow.yml@refs/heads/my_branch 」のように入力します。 |
GITHUB_WORKFLOW_SHA | ワークフロー ファイルのコミット SHA。 |
GITHUB_WORKSPACE | ステップのランナー上の既定の作業ディレクトリと、checkout アクションを使用するときのリポジトリの既定の場所。 たとえば、/home/runner/work/my-repo-name/my-repo-name のようにします。 |
RUNNER_ARCH | ジョブを実行しているランナーのアーキテクチャ。 指定できる値は、X86 、X64 、ARM 、および ARM64 です。 |
RUNNER_DEBUG | これは、デバッグ ログが有効になっている場合にのみ設定され、値は常に 1 です。 独自のジョブ手順で追加のデバッグまたは詳細ログを有効にするためのインジケーターとして役に立ちます。 |
RUNNER_ENVIRONMENT | ジョブを実行しているランナーの環境。 使用可能な値は、GitHub によって提供される GitHub でホストされたランナーの場合は github-hosted 、リポジトリのオーナーによって構成されたセルフホステッド ランナーの場合は self-hosted です。 |
RUNNER_NAME | ジョブを実行しているランナーの名前。 この名前は、リポジトリのランナーと組織レベルで同じ名前を使用できるため、ワークフロー実行で一意でない場合があります。 たとえば、Hosted Agent |
RUNNER_OS | ジョブを実行しているランナーのオペレーティングシステム。 設定可能な値は、Linux 、Windows 、または macOS です。 たとえば、Windows |
RUNNER_TEMP | ランナー上の一時ディレクトリへのパス。 このディレクトリは、各ジョブの開始及び終了時点で空になります。 ランナーのユーザアカウントが削除する権限を持っていない場合、ファイルは削除されないことに注意してください。 たとえば、D:\a\_temp |
RUNNER_TOOL_CACHE | GitHubホストランナーにプレインストールされているツールを含むディレクトリへのパス。 詳しくは、「GitHub ホステッド ランナーの使用」をご覧ください。 たとえば、C:\hostedtoolcache\windows |
Note
ワークフローの実行の URL をジョブの中から使う必要がある場合は、次のように変数を組み合わせることができます: $GITHUB_SERVER_URL/$GITHUB_REPOSITORY/actions/runs/$GITHUB_RUN_ID
オペレーティング システムの検出
既定の環境変数 RUNNER_OS
と対応するコンテキスト プロパティ ${{ runner.os }}
を使用して、異なるオペレーティング システムに使用できる 1 つのワークフロー ファイルを記述できます。 たとえば、ランナーによって使用されるシェルに応じて異なる、環境変数の構文を変更しなくても、オペレーティング システムを macos-latest
から windows-latest
に変更した場合、次のワークフローを正常に実行できます。
on: workflow_dispatch jobs: if-Windows-else: runs-on: macos-latest steps: - name: condition 1 if: runner.os == 'Windows' run: echo "The operating system on the runner is $env:RUNNER_OS." - name: condition 2 if: runner.os != 'Windows' run: echo "The operating system on the runner is not Windows, it's $RUNNER_OS."
on: workflow_dispatch
jobs:
if-Windows-else:
runs-on: macos-latest
steps:
- name: condition 1
if: runner.os == 'Windows'
run: echo "The operating system on the runner is $env:RUNNER_OS."
- name: condition 2
if: runner.os != 'Windows'
run: echo "The operating system on the runner is not Windows, it's $RUNNER_OS."
この例では、2 つの if
ステートメントによって runner
コンテキストの os
プロパティがチェックされ、ランナーのオペレーティング システムが決定されます。 if
条件は GitHub Actions によって処理され、チェックによって true
として解決されるステップのみ、ランナーに送信されます。 ここでは、チェックの 1 つが常に true
となり、もう 1 つが false
になるため、これらのステップの 1 つだけがランナーに送信されます。 ジョブがランナーに送信されると、ステップが実行され、echo
コマンド内の環境変数が適切な構文を使用して補間されます (Windows の PowerShell の場合 $env:NAME
、Linux および macOS の bash と sh の場合 $NAME
)。 この例では、ステートメント runs-on: macos-latest
では 2 番目のステップが実行されます。
ワークフロー内のステップとジョブの間で値を渡す
ジョブの 1 つのステップで値を生成する場合は、既存または新しい環境変数に値を割り当て、これを GITHUB_ENV
環境ファイルに書き込むことで、同じジョブの後続のステップで値を使用できます。 環境ファイルは、アクションによって直接使用することも、run
キーワードを使用してワークフロー ファイル内のシェル コマンドから使用することもできます。 詳しくは、「GitHub Actions のワークフロー コマンド」をご覧ください。
ワークフロー内のあるジョブのステップから、そのワークフロー内の別のジョブのステップに値を渡す場合は、その値をジョブ出力として定義できます。 その後、別のジョブのステップからこのジョブ出力を参照できます。 詳しくは、「GitHub Actions のワークフロー構文」をご覧ください。