Skip to main content

このバージョンの GitHub Enterprise サーバーはこの日付をもって終了となりました: 2023-09-25. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise サーバーにアップグレードしてください。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせください

変数

GitHub は GitHub Actions ワークフロー実行ごとに、既定の変数を設定します。 ワークフロー ファイル内でカスタム変数を設定することもできます。

注: GitHub ホステッド ランナーは、現在 GitHub Enterprise Server でサポートされていません。 GitHub public roadmap で、今後の計画的なサポートの詳細を確認できます。

変数について

変数を使用して、ワークフローで参照する情報を格納できます。 ワークフロー ステップまたはアクション内で変数を参照すると、ワークフローを実行するランナー マシンで変数が補間されます。 アクションまたはワークフロー ステップ内で実行されるコマンドで、変数の作成、読み取り、変更ができます。

独自のカスタム変数を設定したり、GitHub が自動的に設定する既定の変数を使用したり、ランナーの作業環境で設定される他の環境変数を使用したりできます。 変数は大文字と小文字が区別されます。

に対する環境変数の定義

に対してカスタム環境変数を設定する場合、ワークフロー ファイルの env キーを使用して定義できます。 このメソッドで設定されるカスタム変数のスコープは、定義されている要素に制限されます。 次のスコープを設定する変数を定義できます。

  • ワークフロー全体 (ワークフロー ファイルの最上位レベルで env を使用)。
  • ワークフロー内のジョブの内容 (jobs.<job_id>.env を使用)。
  • ジョブ内の特定の手順 (jobs.<job_id>.steps[*].env を使用)。
YAML
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 つのカスタム変数を示しています。 これらの変数の値は、それぞれワークフロー、ジョブ、ステップ レベルで設定され、スコープも設定されます。 コンテキストを使用して変数の値にアクセスする方法について詳しくは、「コンテキストを使用した変数の値へのアクセス」を参照してください。

ランナー環境変数の補間は、ワークフロー ジョブがランナー マシンに送信された後に行われるため、ランナーで使用されるシェルに適切な構文を使用する必要があります。 この例では、ワークフローは ubuntu-latest を指定します。 既定では、Linux ランナーは Bash シェルを使用するため、構文 $NAME を使用する必要があります。 ワークフローで Windows ランナーを指定した場合は、PowerShell $env:NAME の構文を使用します。 シェルの詳細については、「GitHub Actions のワークフロー構文」を参照してください。

環境変数の命名規則

環境変数を設定する場合、既定の環境変数名は使用できません。 既定の環境変数の完全な一覧については、以下の「既定の環境変数」を参照してください。 これらの既定の変数のいずれかの値をオーバーライドしようとすると、割り当ては無視されます。

ファイルシステム上の場所を指すように設定した新しい変数がある場合は、_PATH サフィックスを指定する必要があります。 既定の変数 GITHUB_ENVGITHUB_WORKSPACE は、この規則の例外です。

: ステップで run: env を使用して、ワークフロー ステップで使用できる環境変数のセット全体を一覧表示し、そのステップの出力を調べることができます。

コンテキストを使用した変数の値へのアクセス

コンテキストは、ワークフローの実行、変数、ランナーの環境、ジョブ、ステップに関する情報にアクセスする方法です。詳細については、「コンテキスト」を参照してください。 ワークフローには、さまざまな目的で使用できる他の多くのコンテキストがあります。 ワークフロー内で特定のコンテキストを使用できる場所の詳細については、「コンテキスト」を参照してください。

環境変数の値には、env コンテキストを使用して、アクセスできます。

env コンテキストを使用した環境変数の値へのアクセス

GitHub Actions では、ランナー環境変数に加えて、コンテキストを使用した env キー値の設定および読み取りを行うことができます。 環境変数やコンテキストは、ワークフロー中の様々な場所で利用できます。

ランナー環境変数は、常にランナー マシンで補間されます。 ただし、ワークフローの一部は GitHub Actions によって処理され、ランナーには送信されません。 ワークフロー ファイルのこれらの部分で環境変数を使用することはできません。 その代わりに、コンテキストを使用することができます。 たとえば、ジョブまたはステップがランナーに送信されるかどうかを決定する if 条件は、常に GitHub Actions によって処理されます。 if 条件付きステートメントでコンテキストを使用して、変数の値にアクセスできます。

YAML
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 条件付きステートメントからこの値にアクセスします。

: コンテキストは通常、${{ context.property }} としてドル記号と中かっこを使用して示されます。 if 条件では、${{}} は省略可能ですが、それらを使用する場合は、上記のように比較ステートメント全体を囲む必要があります。

ジョブがランナーに送信される前に処理されるワークフローの一部で、変数の値にアクセスするには、通常 env または github コンテキストを使用します。

Context使用事例
envワークフローで定義されているカスタム変数を参照します。${{ env.MY_VARIABLE }}
githubワークフローの実行とその実行をトリガーしたイベントの情報を参照します。${{ github.repository }}

既定の環境変数

GitHub が設定する既定の環境変数は、ワークフローのどのステップでも使用できます。

既定の環境変数は GitHub によって設定され、ワークフローで定義されていないため、env コンテキストを介してアクセスすることはできません。 しかし、既定の変数のほとんどは、対応する、似た名前のコンテキスト プロパティを持ちます。 たとえば、${{ github.ref }} コンテキスト プロパティを使用してワークフロー処理中に GITHUB_REF 変数の値を読み取ることができます。

GITHUB_* および RUNNER_* という名前の既定の環境変数の値を上書きすることはできません。 現時点では、CI 変数の値を上書きできます。 ただし、これが常に可能になることは保証されていません。 環境変数の設定の詳細については、「1 つのワークフローの環境変数の定義」および「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_ACTIONSGitHub Actions がワークフローを実行しているときは常に true に設定されます。 この変数は、テストがローカルで実行されているときと、GitHub Actionsによって実行されているときを区別するために利用できます。
GITHUB_ACTORワークフローを開始するユーザまたはアプリの名前。 たとえば、octocat のようにします。
GITHUB_API_URLAPI URL を返します。 (例: http(s)://HOSTNAME/api/v3)。
GITHUB_BASE_REFワークフローの実行における base ref の名前または pull request のターゲット ブランチ。 これは、ワークフローの実行をトリガーするイベントが pull_requestpull_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_URLGraphQL API URL を返します。 (例: http(s)://HOSTNAME/api/graphql)。
GITHUB_HEAD_REFワークフローの実行における head ref または pull request のソース ブランチ。 このプロパティは、ワークフローの実行をトリガーするイベントが pull_requestpull_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 」のように入力します。
GITHUB_REF_PROTECTEDワークフローの実行をトリガーした ref に対してブランチ保護が構成されている場合 true
GITHUB_REF_TYPEワークフローの実行をトリガーした ref の種類。 有効な値は branch または tagです。
GITHUB_REPOSITORY所有者およびリポジトリ名。 たとえば、octocat/Hello-World のようにします。
GITHUB_REPOSITORY_OWNERリポジトリ所有者の名前。 たとえば、octocat のようにします。
GITHUB_RETENTION_DAYSワークフロー実行のログと成果物が保持される日数。 たとえば、90 のようにします。
GITHUB_RUN_ATTEMPTリポジトリ内で実行される特定のワークフローの各試行に割り振られる一意の番号。 この番号は、ワークフロー実行の最初の試行時に 1 で始まり、再実行ごとに増加します。 たとえば、3 のようにします。
GITHUB_RUN_ID各ワークフローの一意の番号は、リポジトリ内で実行されます。 この番号は、ワークフローの実行をやり直しても変化しません、 たとえば、1658821493
GITHUB_RUN_NUMBERリポジトリ内の特定のワークフローの各実行に対するユニークな番号。 この番号は、ワークフローの最初の実行時に 1 から始まり、新しい実行ごとに増加します。 この番号は、ワークフローの実行をやり直しても変化しません、 たとえば、3
GITHUB_SERVER_URLGitHub 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_WORKFLOWワークフローの名前。 たとえば、My test workflow のようにします。 ワークフロー ファイルで name を指定していない場合、このプロパティの値は、リポジトリ内にあるワークフロー ファイルの完全なパスになります。
GITHUB_WORKSPACEステップのためのランナー上の既定の作業ディレクトリと、checkout アクションを使うときのリポジトリの既定の場所。 たとえば、/home/runner/work/my-repo-name/my-repo-name のようにします。
RUNNER_ARCHジョブを実行しているランナーのアーキテクチャ。 指定できる値は、X86X64ARM、および ARM64 です。
RUNNER_DEBUGこれは、デバッグ ログが有効になっている場合にのみ設定され、値は常に 1 です。 独自のジョブ手順で追加のデバッグまたは詳細ログを有効にするためのインジケーターとして役に立ちます。
RUNNER_NAMEジョブを実行しているランナーの名前。 たとえば、Hosted Agent
RUNNER_OSジョブを実行しているランナーのオペレーティングシステム。 設定可能な値は、LinuxWindows、または macOS です。 For example, Windows
RUNNER_TEMPランナー上の一時ディレクトリへのパス。 このディレクトリは、各ジョブの開始及び終了時点で空になります。 ランナーのユーザアカウントが削除する権限を持っていない場合、ファイルは削除されないことに注意してください。 たとえば、D:\a\_temp
RUNNER_TOOL_CACHEGitHubホストランナーにプレインストールされているツールを含むディレクトリへのパス。 詳しくは、「Using GitHub-hosted runners」をご覧ください。 たとえば、C:\hostedtoolcache\windows

注: ワークフローの実行の URL をジョブの中から使う必要がある場合は、次のように変数を組み合わせることができます: $GITHUB_SERVER_URL/$GITHUB_REPOSITORY/actions/runs/$GITHUB_RUN_ID

オペレーティング システムの検出

既定の環境変数 RUNNER_OS と対応するコンテキスト プロパティ ${{ runner.os }} を使用して、異なるオペレーティング システムに使用できる 1 つのワークフロー ファイルを記述できます。 たとえば、ランナーによって使用されるシェルに応じて異なる、環境変数の構文を変更しなくても、オペレーティング システムを macos-latest から windows-latest に変更した場合、次のワークフローを正常に実行できます。

YAML
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 のワークフロー構文」を参照してください。