GitHub Actions のワークフロー コマンド

ワークフロー内あるいはアクションのコード内でシェルコマンドを実行する際には、ワークフローコマンドを利用できます。

Tool navigation

この記事の内容

ワークフローコマンドについて

アクションは、 環境変数を設定する、他のアクションに利用される値を出力する、デバッグメッセージを出力ログに追加するなどのタスクを行うため、ランナーマシンとやりとりできます。

ほとんどのワークフロー コマンドが特定の形式で echo コマンドを使用しますが、他のコマンドはファイルへの書き込みによって呼び出されます。 詳細については、「環境ファイル」を参照してください。

ワークフロー コマンドの例

Bash
echo "::workflow-command parameter1={data},parameter2={data}::{command value}"
PowerShell
Write-Output "::workflow-command parameter1={data},parameter2={data}::{command value}"

メモ

ワークフロー コマンドとパラメーターの名前では、大文字と小文字は区別されません。

警告

コマンド プロンプトを使っている場合は、ワークフロー コマンドを使うときに二重引用符 (") を省略してください。

ワークフローコマンドを使ったツールキット関数へのアクセス

actions/toolkit には、ワークフロー コマンドとして実行できる多数の関数が含まれています。 :: 構文を使用して、YAML ファイル内でワークフロー コマンドを実行してください。そうすると、それらのコマンドが stdout を通じてランナーに送信されます。

たとえば、コードを使用してエラー注釈を作成する代わりに、次のようにします:

JavaScript
core.error('Missing semicolon', {file: 'app.js', startLine: 1})

例: エラーの注釈の作成

ワークフローで error コマンドを使用して、同じエラー注釈を作成できます。

YAML
      - name: Create annotation for build error
        run: echo "::error file=app.js,line=1::Missing semicolon"
YAML
      - name: Create annotation for build error
        run: Write-Output "::error file=app.js,line=1::Missing semicolon"

以下の表は、ワークフロー内で使えるツールキット関数を示しています。

ツールキット関数等価なワークフローのコマンド
core.addPathGITHUB_PATH 環境ファイルを使用してアクセス可能
core.debugdebug
core.noticenotice
core.errorerror
core.endGroupendgroup
core.exportVariableGITHUB_ENV 環境ファイルを使用してアクセス可能
core.getInputINPUT_{NAME} 環境変数を使用してアクセス可能
core.getStateSTATE_{NAME} 環境変数を使用してアクセス可能
core.isDebugRUNNER_DEBUG 環境変数を使用してアクセス可能
core.summaryGITHUB_STEP_SUMMARY 環境ファイルを使用してアクセス可能
core.saveStateGITHUB_STATE 環境ファイルを使用してアクセス可能
core.setCommandEchoecho
core.setFailed::error と exit 1 のショートカットとして使用済み
core.setOutputGITHUB_OUTPUT 環境ファイルを使用してアクセス可能
core.setSecretadd-mask
core.startGroupgroup
core.warningwarning

デバッグメッセージの設定

デバッグメッセージをログに出力します。 このコマンドによって設定されたデバッグ メッセージをログで表示するには、ACTIONS_STEP_DEBUG という名前のシークレットを作成し、値を true に設定する必要があります。 詳しくは、「デバッグ ログを有効にする」をご覧ください。

Text
::debug::{message}

例: デバッグ メッセージの設定

Bash
echo "::debug::Set the Octocat variable"
PowerShell
Write-Output "::debug::Set the Octocat variable"

通知メッセージの設定

通知メッセージを作成し、ログにそのメッセージを出力します。 このメッセージは注釈を作成します。これにより、リポジトリ内の特定のファイルにメッセージを関連付けることができます。 必要に応じて、メッセージでファイル内の位置を指定できます。

Text
::notice file={name},line={line},endLine={endLine},title={title}::{message}
パラメーター値必須Default
titleカスタム タイトルいいえなし
fileFilenameいいえ.github
col列番号 (1 から始まる)いいえなし
endColumn終わりの列番号いいえなし
line行番号 (1 から始まる)いいえ1
endLine終わりの行番号いいえ1

例: 通知メッセージの設定

Bash
echo "::notice file=app.js,line=1,col=5,endColumn=7::Missing semicolon"
PowerShell
Write-Output "::notice file=app.js,line=1,col=5,endColumn=7,title=YOUR-TITLE::Missing semicolon"

警告メッセージの設定

警告メッセージを作成し、ログにそのメッセージを出力します。 このメッセージは注釈を作成します。これにより、リポジトリ内の特定のファイルにメッセージを関連付けることができます。 必要に応じて、メッセージでファイル内の位置を指定できます。

Text
::warning file={name},line={line},endLine={endLine},title={title}::{message}
パラメーター値必須Default
titleカスタム タイトルいいえなし
fileFilenameいいえ.github
col列番号 (1 から始まる)いいえなし
endColumn終わりの列番号いいえなし
line行番号 (1 から始まる)いいえ1
endLine終わりの行番号いいえ1

例: 警告メッセージの設定

Bash
echo "::warning file=app.js,line=1,col=5,endColumn=7,title=YOUR-TITLE::Missing semicolon"
PowerShell
Write-Output "::warning file=app.js,line=1,col=5,endColumn=7,title=YOUR-TITLE::Missing semicolon"

エラーメッセージの設定

エラーメッセージを作成し、ログにそのメッセージを出力します。 このメッセージは注釈を作成します。これにより、リポジトリ内の特定のファイルにメッセージを関連付けることができます。 必要に応じて、メッセージでファイル内の位置を指定できます。

Text
::error file={name},line={line},endLine={endLine},title={title}::{message}
パラメーター値必須Default
titleカスタム タイトルいいえなし
fileFilenameいいえ.github
col列番号 (1 から始まる)いいえなし
endColumn終わりの列番号いいえなし
line行番号 (1 から始まる)いいえ1
endLine終わりの行番号いいえ1

例: エラー メッセージの設定

Bash
echo "::error file=app.js,line=1,col=5,endColumn=7,title=YOUR-TITLE::Missing semicolon"
PowerShell
Write-Output "::error file=app.js,line=1,col=5,endColumn=7,title=YOUR-TITLE::Missing semicolon"

ログの行のグループ化

展開可能なグループをログ中に作成します。 グループを作成するには、group コマンドを使用して title を指定します。 ログに出力する group と endgroup コマンド間のすべての内容は、ログで展開可能なエントリ内で入れ子になります。

Text
::group::{title}
::endgroup::

例: ログの行のグループ化

YAML
jobs:
  bash-example:
    runs-on: ubuntu-latest
    steps:
      - name: Group of log lines
        run: |
            echo "::group::My title"
            echo "Inside group"
            echo "::endgroup::"
YAML
jobs:
  powershell-example:
    runs-on: windows-latest
    steps:
      - name: Group of log lines
        run: |
            Write-Output "::group::My title"
            Write-Output "Inside group"
            Write-Output "::endgroup::"

ワークフロー ステップのログのスクリーンショット。 2 行目の [My title] は展開されたグループです。 次の行の "Inside group" は、下にインデントされています。

ログ中の値のマスク

Text
::add-mask::{value}

値をマスクすることにより、文字列または値がログに出力されることを防ぎます。 空白で区切られた、マスクされる各単語は、* という文字に置き換えられます。 マスクの value には、環境変数または文字列を使用できます。 値をマスクすると、シークレットとして扱われ、ランナーで編集されます。 たとえば、値をマスクした後は、その値を出力として設定することはできません。

例: 文字列のマスク

ログに "Mona The Octocat" を出力すると、"***" と表示されます。

Bash
echo "::add-mask::Mona The Octocat"
PowerShell
Write-Output "::add-mask::Mona The Octocat"

警告

シークレットをビルド ログに出力したり、その他のワークフロー コマンド内で使ったりする前に、シークレットを 'add-mask' に必ず登録してください。

例: 環境変数のマスク

ログに変数 MY_NAME または値 "Mona The Octocat" を出力すると、"Mona The Octocat" の代わりに "***" と表示されます。

YAML
jobs:
  bash-example:
    runs-on: ubuntu-latest
    env:
      MY_NAME: "Mona The Octocat"
    steps:
      - name: bash-version
        run: echo "::add-mask::$MY_NAME"
YAML
jobs:
  powershell-example:
    runs-on: windows-latest
    env:
      MY_NAME: "Mona The Octocat"
    steps:
      - name: powershell-version
        run: Write-Output "::add-mask::$env:MY_NAME"

例: 1 つのジョブ内での生成された出力のマスク

1 つのジョブから別のジョブにシークレットを渡す必要がない場合は、次を行うことができます。

  1. シークレットを生成する (出力は行いません)。
  2. add-mask を使ってマスクする。
  3. GITHUB_OUTPUT を使って、ジョブ内の他のステップにシークレットを使えるようにする。
YAML
on: push
jobs:
  generate-a-secret-output:
    runs-on: ubuntu-latest
    steps:
      - id: sets-a-secret
        name: Generate, mask, and output a secret
        run: |
          the_secret=$((RANDOM))
          echo "::add-mask::$the_secret"
          echo "secret-number=$the_secret" >> "$GITHUB_OUTPUT"
      - name: Use that secret output (protected by a mask)
        run: |
          echo "the secret number is ${{ steps.sets-a-secret.outputs.secret-number }}"
YAML
on: push
jobs:
  generate-a-secret-output:
    runs-on: ubuntu-latest
    steps:
      - id: sets-a-secret
        name: Generate, mask, and output a secret
        shell: pwsh
        run: |
          Set-Variable -Name TheSecret -Value (Get-Random)
          Write-Output "::add-mask::$TheSecret"
          "secret-number=$TheSecret" >> $env:GITHUB_OUTPUT
      - name: Use that secret output (protected by a mask)
        shell: pwsh
        run: |
          Write-Output "the secret number is ${{ steps.sets-a-secret.outputs.secret-number }}"

例: ジョブまたはワークフロー間でのシークレットのマスクと引き渡し

マスクされたシークレットをジョブまたはワークフロー間で渡す場合は、そのシークレットをストアに格納してから後続のジョブまたはワークフローで取得する必要があります。

セットアップ

  1. ワークフロー中に生成するシークレットを格納するようにシークレット ストアを設定します。 たとえば、Vault です。
  2. そのシークレット ストアに対する読み取りと書き込みのキーを生成します。 キーをリポジトリ シークレットとして格納します。 次のワークフロー例では、シークレット名は SECRET_STORE_CREDENTIALS です。 詳しくは、「GitHub Actions でのシークレットの使用」をご覧ください。

ワークフロー

メモ

このワークフローでは、架空のシークレット ストア secret-store を使い、これには架空のコマンド store-secret と retrieve-secret が含まれています。 some/secret-store@ 27b31702a0e7fc50959f5ad993c78deac1bdfc29 は架空のアクションです。これを実行すると、secret-store アプリケーションがインストールされ、instance と credentials に接続するように構成されます。

YAML
on: push

jobs:
  secret-generator:
    runs-on: ubuntu-latest
    outputs:
      handle: ${{ steps.generate-secret.outputs.handle }}
    steps:
    - uses: some/secret-store@27b31702a0e7fc50959f5ad993c78deac1bdfc29
      with:
        credentials: ${{ secrets.SECRET_STORE_CREDENTIALS }}
        instance: ${{ secrets.SECRET_STORE_INSTANCE }}
    - name: generate secret
      id: generate-secret
      shell: bash
      run: |
        GENERATED_SECRET=$((RANDOM))
        echo "::add-mask::$GENERATED_SECRET"
        SECRET_HANDLE=$(secret-store store-secret "$GENERATED_SECRET")
        echo "handle=$SECRET_HANDLE" >> "$GITHUB_OUTPUT"
  secret-consumer:
    runs-on: macos-latest
    needs: secret-generator
    steps:
    - uses: some/secret-store@27b31702a0e7fc50959f5ad993c78deac1bdfc29
      with:
        credentials: ${{ secrets.SECRET_STORE_CREDENTIALS }}
        instance: ${{ secrets.SECRET_STORE_INSTANCE }}
    - name: use secret
      shell: bash
      run: |
        SECRET_HANDLE="${{ needs.secret-generator.outputs.handle }}"
        RETRIEVED_SECRET=$(secret-store retrieve-secret "$SECRET_HANDLE")
        echo "::add-mask::$RETRIEVED_SECRET"
        echo "We retrieved our masked secret: $RETRIEVED_SECRET"
YAML
on: push

jobs:
  secret-generator:
    runs-on: ubuntu-latest
    steps:
    - uses: some/secret-store@27b31702a0e7fc50959f5ad993c78deac1bdfc29
      with:
        credentials: ${{ secrets.SECRET_STORE_CREDENTIALS }}
        instance: ${{ secrets.SECRET_STORE_INSTANCE }}
    - name: generate secret
      shell: pwsh
      run: |
        Set-Variable -Name Generated_Secret -Value (Get-Random)
        Write-Output "::add-mask::$Generated_Secret"
        Set-Variable -Name Secret_Handle -Value (Store-Secret "$Generated_Secret")
        "handle=$Secret_Handle" >> $env:GITHUB_OUTPUT
  secret-consumer:
    runs-on: macos-latest
    needs: secret-generator
    steps:
    - uses: some/secret-store@27b31702a0e7fc50959f5ad993c78deac1bdfc29
      with:
        credentials: ${{ secrets.SECRET_STORE_CREDENTIALS }}
        instance: ${{ secrets.SECRET_STORE_INSTANCE }}
    - name: use secret
      shell: pwsh
      run: |
        Set-Variable -Name Secret_Handle -Value "${{ needs.secret-generator.outputs.handle }}"
        Set-Variable -Name Retrieved_Secret -Value (Retrieve-Secret "$Secret_Handle")
        echo "::add-mask::$Retrieved_Secret"
        echo "We retrieved our masked secret: $Retrieved_Secret"

ワークフローコマンドの停止と開始

ワークフローコマンドの処理を停止します。 この特殊コマンドを使うと、意図せずワークフローコマンドを実行することなくいかなるログも取れます。 たとえば、コメントがあるスクリプト全体を出力するためにログ取得を停止できます。

Text
::stop-commands::{endtoken}

ワークフロー コマンドの処理を停止するには、固有のトークンを stop-commands に渡します。 ワークフロー コマンドの処理を再開するには、ワークフロー コマンドを停止するために使用したトークンと同じものを渡します。

警告

ランダムに生成された、実行ごとに固有のトークンを使うようにしてください。

Text
::{endtoken}::

例: ワークフロー コマンドの停止と開始

YAML
jobs:
  workflow-command-job:
    runs-on: ubuntu-latest
    steps:
      - name: Disable workflow commands
        run: |
          echo '::warning:: This is a warning message, to demonstrate that commands are being processed.'
          stopMarker=$(uuidgen)
          echo "::stop-commands::$stopMarker"
          echo '::warning:: This will NOT be rendered as a warning, because stop-commands has been invoked.'
          echo "::$stopMarker::"
          echo '::warning:: This is a warning again, because stop-commands has been turned off.'
YAML
jobs:
  workflow-command-job:
    runs-on: windows-latest
    steps:
      - name: Disable workflow commands
        run: |
          Write-Output '::warning:: This is a warning message, to demonstrate that commands are being processed.'
          $stopMarker = New-Guid
          Write-Output "::stop-commands::$stopMarker"
          Write-Output '::warning:: This will NOT be rendered as a warning, because stop-commands has been invoked.'
          Write-Output "::$stopMarker::"
          Write-Output '::warning:: This is a warning again, because stop-commands has been turned off.'

pre及びpostアクションへの値の送信

GITHUB_STATE にあるファイルに書き込むことで、ワークフローの pre: または post: アクションと共有するための環境変数を作成できます。 たとえば、pre: アクションでファイルを作成し、そのファイルの場所を main: アクションに渡し、post: アクションを使用してファイルを削除できます。 あるいは、main: アクションでファイルを作成し、そのファイルの場所を post: アクションに渡し、さらに post: アクションを使用してファイルを削除することもできます。

複数の pre: または post: アクションがある場合、GITHUB_STATE に書き込まれたアクションでのみ保存された値にアクセスできます。 post: アクションについて詳しくは、「メタデータ構文リファレンス」をご覧ください。

GITHUB_STATE ファイルは、アクション内でのみ使用できます。 保存された値は、STATE_ というプレフィックスが付いた環境変数として保存されます。

この例では、JavaScript を使用して GITHUB_STATE ファイルに書き込みます。 結果の環境変数は、STATE_processID という名前になり、値が 12345 になります。

JavaScript
import * as fs from 'fs'
import * as os from 'os'

fs.appendFileSync(process.env.GITHUB_STATE, `processID=12345${os.EOL}`, {
  encoding: 'utf8'
})

この後、STATE_processID 変数は main アクションで実行されるクリーンアップ スクリプトでのみ利用できます。 この例は main で実行され、JavaScript を使用して STATE_processID 環境変数に割り当てられた値を表示します。

JavaScript
console.log("The running PID from the main action is: " + process.env.STATE_processID);

環境ファイル

ワークフローの実行中に、ランナーは特定のアクションを実行する際に使用できる一時ファイルを生成します。 これらのファイルへのパスは、GitHub の既定の環境変数を使用してアクセスおよび編集できます。 「変数リファレンス」を参照してください。 コマンドを適切に処理するには、これらのファイルに書き込むときに UTF-8 エンコーディングを使用する必要があります。 複数のコマンドを、改行で区切って同じファイルに書き込むことができます。 GitHub アクションで環境変数を使用するには、特定の GitHub Actions コマンドを使用して .env ファイルを作成または変更します。

方法は以下のとおりです。

YAML
name: Example Workflow for Environment Files

on: push

jobs:
  set_and_use_env_vars:
    runs-on: ubuntu-latest
    steps:
      - name: Set environment variable
        run: echo "MY_ENV_VAR=myValue" >> $GITHUB_ENV

      - name: Use environment variable
        run: |
          echo "The value of MY_ENV_VAR is $MY_ENV_VAR"

別の例として、これを使用して、ビルド タイムスタンプ、コミット SHA、アーティファクト名などのメタデータを格納します:

YAML
steps:
  - name: Store build timestamp
    run: echo "BUILD_TIME=$(date +'%T')" >> $GITHUB_ENV

  - name: Deploy using stored timestamp
    run: echo "Deploying at $BUILD_TIME"

メモ

PowerShell バージョン 5.1 以前 (shell: powershell) では UTF-8 が既定で使われないため、UTF-8 エンコードを指定する必要があります。 次に例を示します。

YAML
jobs:
  legacy-powershell-example:
    runs-on: windows-latest
    steps:
      - shell: powershell
        run: |
          "mypath" | Out-File -FilePath $env:GITHUB_PATH -Encoding utf8 -Append

PowerShell Core バージョン 6 以上 (shell: pwsh) では、UTF-8 が既定で使用されます。 次に例を示します。

YAML
jobs:
  powershell-core-example:
    runs-on: windows-latest
    steps:
      - shell: pwsh
        run: |
          "mypath" >> $env:GITHUB_PATH

環境変数の設定

メモ

問題を避けるには、使っているオペレーティング システムとシェルの動作に関係なく、環境変数を大文字と小文字を区別するものとして扱うことをお勧めします。

Bash
echo "{environment_variable_name}={value}" >> "$GITHUB_ENV"

  • PowerShell バージョン 6 以上を使用:

    PowerShell
    "{environment_variable_name}={value}" >> $env:GITHUB_ENV

  • PowerShell バージョン 5.1 以下を使用:

    PowerShell
    "{environment_variable_name}={value}" | Out-File -FilePath $env:GITHUB_ENV -Encoding utf8 -Append

環境変数を定義または更新し、これを GITHUB_ENV 環境ファイルに書き込むことで、ワークフロー ジョブの後続のステップで環境変数が利用できるようになります。 環境変数を作成または更新するステップは、新しい値にアクセスできませんが、ジョブにおける後続のすべてのステップはアクセスできます。

GITHUB_* および RUNNER_* という名前の既定の環境変数の値を上書きすることはできません。 現時点では、CI 変数の値を上書きできます。 ただし、これが常に可能になることは保証されていません。既定の環境変数について詳しくは、「変数に情報を格納する」をご覧ください。

メモ

セキュリティ上の制限のため、GITHUB_ENV を使って NODE_OPTIONS 環境変数を設定することはできません。

環境変数を GITHUB_ENV に書き込む例

YAML
steps:
  - name: Set the value
    id: step_one
    run: |
      echo "action_state=yellow" >> "$GITHUB_ENV"
  - name: Use the value
    id: step_two
    run: |
      printf '%s\n' "$action_state" # This will output 'yellow'
YAML
steps:
  - name: Set the value
    id: step_one
    run: |
      "action_state=yellow" >> $env:GITHUB_ENV
  - name: Use the value
    id: step_two
    run: |
      Write-Output "$env:action_state" # This will output 'yellow'

複数行の文字列

複数行の文字列の場合、次の構文で区切り文字を使用できます。

Text
{name}<<{delimiter}
{value}
{delimiter}

警告

使って区切り記号が、値内のそれ自体の行に含まれないことを確認してくだい。 値が完全に任意の場合は、この形式を使用しないでください。 代わりに、値をファイルに書き込みます。

複数行文字列の例

この例では、区切り文字として EOF を使用し、JSON_RESPONSE 環境変数を curl の応答の値に設定します。

YAML
steps:
  - name: Set the value in bash
    id: step_one
    run: |
      {
        echo 'JSON_RESPONSE<<EOF'
        curl https://example.com
        echo EOF
      } >> "$GITHUB_ENV"
YAML
steps:
  - name: Set the value in pwsh
    id: step_one
    run: |
      $EOF = (New-Guid).Guid
      "JSON_RESPONSE<<$EOF" >> $env:GITHUB_ENV
      (Invoke-WebRequest -Uri "https://example.com").Content >> $env:GITHUB_ENV
      "$EOF" >> $env:GITHUB_ENV
    shell: pwsh

出力パラメータの設定

ステップの出力パラメーターを設定します。 後で出力値を取得するには、ステップで id を定義する必要があることに注意してください。 「複数行の文字列」セクションで使ったのと同じ手法で複数行の出力値を設定して、複数行の環境変数を定義できます。

Bash
echo "{name}={value}" >> "$GITHUB_OUTPUT"
PowerShell
"{name}=value" >> $env:GITHUB_OUTPUT

出力パラメーターの設定例

この例では、SELECTED_COLOR 出力パラメーターを設定し、後でそれを取得する方法を示します。

YAML
      - name: Set color
        id: color-selector
        run: echo "SELECTED_COLOR=green" >> "$GITHUB_OUTPUT"
      - name: Get color
        env:
          SELECTED_COLOR: ${{ steps.color-selector.outputs.SELECTED_COLOR }}
        run: echo "The selected color is $SELECTED_COLOR"

この例では、SELECTED_COLOR 出力パラメーターを設定し、後でそれを取得する方法を示します。

YAML
      - name: Set color
        id: color-selector
        run: |
            "SELECTED_COLOR=green" >> $env:GITHUB_OUTPUT
      - name: Get color
        env:
          SELECTED_COLOR: ${{ steps.color-selector.outputs.SELECTED_COLOR }}
        run: Write-Output "The selected color is $env:SELECTED_COLOR"

ジョブの概要の追加

Bash
echo "{markdown content}" >> $GITHUB_STEP_SUMMARY
PowerShell
"{markdown content}" >> $env:GITHUB_STEP_SUMMARY

ジョブごとにいくつかのカスタム Markdown を設定して、ワークフロー実行の概要ページに表示されるようにすることができます。 ジョブの概要を使用して、テスト結果の概要といった独自の内容を表示およびグループ化できます。これにより、ワークフロー実行の結果を表示するユーザーが、実行に関連する重要な情報 (エラーなど) を確認するためにログを調べる必要がなくなります。

ジョブの概要では GitHub Flavored Markdown がサポートされていて、ステップの Markdown コンテンツを GITHUB_STEP_SUMMARY 環境ファイルに追加できます。 GITHUB_STEP_SUMMARY は、ジョブのステップごとに固有のものです。 GITHUB_STEP_SUMMARY が参照するステップごとのファイルについて詳しくは、「環境ファイル」をご覧ください。

ジョブが完了すると、ジョブにおけるすべてのステップの概要が 1 つのジョブの概要にグループ化され、ワークフロー実行の概要ページに表示されます。 複数のジョブが概要を生成する場合、ジョブの概要の順序はジョブの完了時間順になります。

ジョブの概要の追加例

Bash
echo "### Hello world! :rocket:" >> $GITHUB_STEP_SUMMARY
PowerShell
"### Hello world! :rocket:" >> $env:GITHUB_STEP_SUMMARY

ワークフロー実行時の概要ページのスクリーンショット。 "example summary" の下に "Hello world!" と ロケットの絵文字があります。

複数行の Markdown コンテンツ

複数行の Markdown コンテンツの場合は、>> を使用して、現在のステップのコンテンツを連続して追加できます。 追加操作のたびに、改行文字が自動的に追加されます。

複数行の Markdown コンテンツの例

- name: Generate list using Markdown
  run: |
    echo "This is the lead in sentence for the list" >> $GITHUB_STEP_SUMMARY
    echo "" >> $GITHUB_STEP_SUMMARY # this is a blank line
    echo "- Lets add a bullet point" >> $GITHUB_STEP_SUMMARY
    echo "- Lets add a second bullet point" >> $GITHUB_STEP_SUMMARY
    echo "- How about a third one?" >> $GITHUB_STEP_SUMMARY

- name: Generate list using Markdown
  run: |
    "This is the lead in sentence for the list" >> $env:GITHUB_STEP_SUMMARY
    "" >> $env:GITHUB_STEP_SUMMARY # this is a blank line
    "- Lets add a bullet point" >> $env:GITHUB_STEP_SUMMARY
    "- Lets add a second bullet point" >> $env:GITHUB_STEP_SUMMARY
    "- How about a third one?" >> $env:GITHUB_STEP_SUMMARY

ジョブの概要の上書き

現在のステップのすべてのコンテンツをクリアするには、> を使用して、Bash で以前に追加したコンテンツを上書きするか、PowerShell で -Append を削除します。

ジョブの概要の上書き例

- name: Overwrite Markdown
  run: |
    echo "Adding some Markdown content" >> $GITHUB_STEP_SUMMARY
    echo "There was an error, we need to clear the previous Markdown with some new content." > $GITHUB_STEP_SUMMARY

- name: Overwrite Markdown
  run: |
    "Adding some Markdown content" >> $env:GITHUB_STEP_SUMMARY
    "There was an error, we need to clear the previous Markdown with some new content." >> $env:GITHUB_STEP_SUMMARY

ジョブの概要の削除

現在のステップの概要を完全に削除するには、GITHUB_STEP_SUMMARY が参照するファイルを削除します。

ジョブの概要の削除例

- name: Delete all summary content
  run: |
    echo "Adding Markdown content that we want to remove before the step ends" >> $GITHUB_STEP_SUMMARY
    rm $GITHUB_STEP_SUMMARY

- name: Delete all summary content
  run: |
    "Adding Markdown content that we want to remove before the step ends" >> $env:GITHUB_STEP_SUMMARY
    Remove-Item $env:GITHUB_STEP_SUMMARY

ステップが完了すると、ジョブの概要がアップロードされ、後続のステップは以前にアップロードされた Markdown コンテンツを変更できません。 概要では、誤って追加された可能性があるシークレットが自動的にマスクされます。 ジョブの概要に削除する必要がある機密情報が含まれている場合は、ワークフロー実行全体を削除して、そのジョブの概要をすべて削除できます。 詳しくは、「ワークフロー実行の削除」をご覧ください。

ステップの分離と制限

ジョブの概要はステップ間で分離されていて、各ステップのサイズは最大 1 MiB に制限されています。 分離がステップ間で適用されるため、1 つのステップにおいて Markdown の形式が誤っている可能性があっても、後続のステップで Markdown のレンダリングが中断することはありません。 ステップに 1 MiB を超えるコンテンツが追加された場合、ステップのアップロードは失敗し、エラーの注釈が作成されます。 ジョブの概要のアップロード エラーは、ステップまたはジョブの全体的な状態には影響しません。 ジョブごとに、ステップのジョブの概要が最大 20 件表示されます。

システムパスの追加

システムの PATH 変数の先頭にディレクトリを追加し、自動的に現在のジョブにおける後続のすべてのアクションで利用できるようにします。現在実行中のアクションは、更新されたパス変数にアクセスできません。 ジョブに現在定義されているパスを確認するには、ステップまたはアクションで echo "$PATH" を使うことができます。

システム パスの追加例

この例では、ユーザーの $HOME/.local/bin ディレクトリを PATH に追加する方法を示しています。

Bash
echo "$HOME/.local/bin" >> "$GITHUB_PATH"

この例では、ユーザーの $env:HOMEPATH/.local/bin ディレクトリを PATH に追加する方法を示しています。

PowerShell
"$env:HOMEPATH/.local/bin" | Out-File -FilePath "$env:GITHUB_PATH" -Append
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy