メタデータ構文リファレンス

リポジトリでタスクを実行するアクションを作成できます。 カスタム アクションを行う場合は、YAML 構文を使用するメタデータ ファイルが必要です。

この記事で

メモ

Docker コンテナーと JavaScript のアクション、および複合アクションを構築できます。 アクションには、アクションの入力、出力、実行構成を定義しているメタデータ ファイルが必要です。 アクション メタデータ ファイルでは YAML 構文を使い、メタデータ ファイル名は action.yml または action.yaml である必要があります。 推奨される形式は action.yml です。

name

          **必須** アクションの名前。 GitHub の `name` タブには **** が表示され、各ジョブのアクションを視覚的に特定するのに役立ちます。

author

          **省略可能** アクションの作成者の名前。

description

          **必須** アクションの簡単な説明。

inputs

          **省略可能** 入力パラメーターでは、実行時にアクションで使用するデータを指定できます。 GitHubは、inputsパラメータを環境変数として保存します。 入力IDには小文字を使うことをおすすめします。

例: 入力の指定

この例では、num-octocats と octocat-eye-color という 2 つの入力を構成しています。 num-octocats 入力は必須ではなく、既定の値は 1 になります。 octocat-eye-color は必須で、既定値はありません。

メモ

入力が指定されていない場合、required: true を使用するアクションは自動的にエラーを返しません。

このアクションが使用されているワークフロー ファイルでは、with キーワードを使って、octocat-eye-color の入力値を設定できます。 with 構文の詳細については、「GitHub Actions　のワークフロー構文」を参照してください。

inputs:
  num-octocats:
    description: 'Number of Octocats'
    required: false
    default: '1'
  octocat-eye-color:
    description: 'Eye color of the Octocats'
    required: true

入力を指定すると、GitHub により、その入力に対して、INPUT_<VARIABLE_NAME> という名前の環境変数が作成されます。 作成された環境変数では、入力名を大文字に変換し、空白を _ 文字に置き換えます。

アクションが composite を使用して書き込まれている場合は、自動的に INPUT_<VARIABLE_NAME> が取得されません。 複合アクションを使用すると、inputsコンテキスト リファレンス を使用してアクション入力にアクセスできます。

Docker コンテナー アクションの環境変数にアクセスするには、アクション メタデータ ファイルで args キーワードを使用して入力を渡す必要があります。 Docker コンテナー アクションのアクション メタデータ ファイルの詳細については、「Docker コンテナーのアクションを作成する」を参照してください。

たとえば、ワークフローで num-octocats および octocat-eye-color 入力が定義されている場合は、アクション コードで、INPUT_NUM-OCTOCATS および INPUT_OCTOCAT-EYE-COLOR 環境変数を使用して入力の値を読み取ることができます。

inputs.<input_id>

          **必須** 入力に関連付ける `string` 識別子。 
          `<input_id>` の値は、入力のメタデータのマップです。 
          `<input_id>` は、`inputs` オブジェクト内の一意識別子である必要があります。 
          `<input_id>` は文字または `_` で始まり、英数字、`-`、あるいは `_` のみを含める必要があります。

inputs.<input_id>.description

          **必須** 入力パラメーターの `string` の説明。

inputs.<input_id>.required

          **省略可能** アクションに入力パラメーターが必要かどうかを示す `boolean`。 パラメーターが必要な場合は、`true` に設定します。

inputs.<input_id>.default

          **省略可能** 既定値を表す `string`。 デフォルト値は、入力パラメーターがワークフローファイルで指定されなかった場合に使われます。

inputs.<input_id>.deprecationMessage

          **省略可能** 入力パラメーターが使用されている場合、この `string` は警告メッセージとしてログに記録されます。 この警告で入力が 終了 であることをユーザに通知し、その他の方法を知らせることができます。

Docker コンテナーおよび JavaScript アクションのための outputs

          **省略可能** 出力パラメーターを使用すると、アクションで設定されるデータを宣言できます。 ワークフローで後に実行されるアクションは、先行して実行されたアクションが設定した出力データを利用できます。 たとえば、2つの入力を加算(x + y = z)するアクションがあれば、そのアクションは他のアクションが入力として利用できる合計値(z)を出力できます。

データ再利用可能なアクション.出力制限 %}

メタデータファイル中でアクション内の出力を宣言しなくても、出力を設定してワークフロー中で利用することはできます。 アクションで出力を設定する方法の詳細については、「GitHub Actions のワークフロー コマンド」を参照してください。

例: Docker コンテナーと JavaScript アクションの出力の宣言

outputs:
  sum: # id of the output
    description: 'The sum of the inputs'

outputs.<output_id>

          **必須** 出力に関連付ける `string` 識別子。 
          `<output_id>` の値は、出力のメタデータのマップです。 
          `<output_id>` は、`outputs` オブジェクト内の一意識別子である必要があります。 
          `<output_id>` は文字または `_` で始まり、英数字、`-`、あるいは `_` のみを含める必要があります。

outputs.<output_id>.description

          **必須** 出力パラメーターの `string` の説明。


          `outputs` 複合アクション用

          **省略可能**`outputs` では `outputs.<output_id>` および `outputs.<output_id>.description` と同じパラメーターが使用されます (「[Docker コンテナーと JavaScript アクションの `outputs`](#outputs-for-docker-container-and-javascript-actions)」を参照) が、`value` トークンも含まれます。

データ再利用可能なアクション.出力制限 %}

例: 複合アクションの出力の宣言

outputs:
  random-number:
    description: "Random number"
    value: ${{ steps.random-number-generator.outputs.random-id }}
runs:
  using: "composite"
  steps:
    - id: random-number-generator
      run: echo "random-id=$(echo $RANDOM)" >> $GITHUB_OUTPUT
      shell: bash

outputs.<output_id>.value

          **必須** 出力パラメーターがマップされる値。 これは、`string` またはコンテキスト付きの式に設定できます。 たとえば、`steps` コンテキストを使用して、出力の `value` をステップの出力値に設定できます。

コンテキスト構文の使い方の詳細については、「コンテキスト リファレンス」を参照してください。

runs

          **必須** これが JavaScript アクション、複合アクション、Docker コンテナー アクションのいずれであるか、およびアクションの実行方法を指定します。


          `runs` JavaScript のアクション用

          **必須** アクションのコードへのパスと、コードの実行に使用されるランタイムを構成します。

例: Node.js v24 の使用

runs:
  using: 'node24'
  main: 'main.js'


          `runs.using` JavaScript のアクション用

          **必須**[`main`](#runsmain) で指定されたコードを実行するために使用されるランタイム。
  • Node.js v20 では node20 を使用する。
  • Node.js v24は node24 を使います。

runs.main

          **必須** アクション コードを含むファイル。 
          [
          `using`
          ](#runsusing-for-javascript-actions) で指定されたランタイムでこのファイルが実行されます。

runs.pre

          **省略可能**`main:` アクションが開始される前に、ジョブの開始時にスクリプトを実行できます。 たとえば、`pre:` を使って必要なセットアップ スクリプトを実行できます。 
          [
          `using`
          ](#runsusing-for-javascript-actions) 構文で指定されたランタイムによりこのファイルが実行されます。 
          `pre:` アクションは常に既定で実行されますが、[`runs.pre-if`](#runspre-if) を使用してこれをオーバーライドすることはできます。

メモ

          `runs.pre` はローカル アクションではサポートされていません。

この例では、pre: アクションによって setup.js というスクリプトが実行されます。

runs:
  using: 'node24'
  pre: 'setup.js'
  main: 'index.js'
  post: 'cleanup.js'

runs.pre-if

          **省略可能** でアクションの実行条件を定義できます。 
          `pre:` アクションは、`pre-if` 内の条件が満たされた場合にのみ実行されます。 設定されていない場合、`pre-if` は既定で `always()` に設定されます。 
          `pre-if` では、ステータス チェック関数は、アクション自体の状態ではなく、ジョブの状態に対して評価されます。

まだステップが実行されていないので、step コンテキストは利用できないことに注意してください。

以下の例では、cleanup.js は Linux ベースのランナーでのみ実行されます。

  pre: 'cleanup.js'
  pre-if: runner.os == 'linux'

runs.post

          **省略可能**`main:` アクションが完了したら、ジョブの終了時にスクリプトを実行できます。 たとえば、`post:` を使って特定のプロセスを終了させたり、不要なファイルを削除したりできます。 
          [
          `using`
          ](#runsusing-for-javascript-actions) 構文で指定されたランタイムによりこのファイルが実行されます。

この例では、post: アクションによって cleanup.js というスクリプトが実行されます。

runs:
  using: 'node24'
  main: 'index.js'
  post: 'cleanup.js'

          `post:` アクションは常に既定で実行されますが、`post-if` を使用してこれをオーバーライドすることはできます。

runs.post-if

          **省略可能** でアクションの実行条件を定義できます。 
          `post:` アクションは、`post-if` 内の条件が満たされた場合にのみ実行されます。 設定されていない場合、`post-if` は既定で `always()` に設定されます。 
          `post-if` では、ステータス チェック関数は、アクション自体の状態ではなく、ジョブの状態に対して評価されます。

たとえば、この cleanup.js は Linux ベースのランナーでのみ実行されます。

  post: 'cleanup.js'
  post-if: runner.os == 'linux'


          `runs` 複合アクション用

          **必須** 複合アクションへのパスを構成します。


          `runs.using` 複合アクション用

          **必須** この値を `'composite'` に設定する必要があります。

runs.steps

          **必須** このアクションで実行する予定のステップ。 これらは、`run` ステップまたは `uses` ステップにすることができます。

runs.steps[*].run

          **省略可能** 実行したいコマンド。 これは、インラインでも、アクション リポジトリ内のスクリプトでもかまいません。

runs:
  using: "composite"
  steps:
    - run: ${{ github.action_path }}/test/script.sh
      shell: bash

          `$GITHUB_ACTION_PATH` を使用することもできます。

runs:
  using: "composite"
  steps:
    - run: $GITHUB_ACTION_PATH/script.sh
      shell: bash

詳しくは、「コンテキスト リファレンス」をご覧ください。

runs.steps[*].shell

          **省略可能** コマンドを実行したいシェル。 「[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsshell)」に記載されているシェルのいずれかを使用できます。 
          `run` が設定されている場合は必須です。

runs.steps[*].if

          **省略可能**`if` 条件文を使って、条件が満たされなければ、ステップを実行しないようにすることができます。 条件文を作成するには、サポートされている任意のコンテキストや式が使えます。

if 条件の中で式を使う際には、任意で式構文 ${{ }} を省略できます。これは、GitHub Actions が if 条件を式として自動的に評価するためです。 ただし、この例外はどこでも適用されるわけではありません。

! は YAML 形式で予約された表記であるため、必ず${{ }} 構文の式を使用するか、式が ! で始まる場合は ''、""、または () でエスケープする必要があります。 次に例を示します。

if: ${{ ! startsWith(github.ref, 'refs/tags/') }}

詳細については、「ワークフロー内とアクション内で式を評価する」を参照してください。

          **例: コンテキストの使用**

このステップは、イベントの種類が pull_request で、イベント アクションが unassigned である場合にのみ実行されます。

steps:
  - run: echo This event is a pull request that had an assignee removed.
    if: ${{ github.event_name == 'pull_request' && github.event.action == 'unassigned' }}

          **例: ステータス チェック関数の使用**

複合アクションの前のステップが失敗した場合にのみ、my backup step が実行されます。 詳しくは、「ワークフロー内とアクション内で式を評価する」をご覧ください。

steps:
  - name: My first step
    uses: octo-org/action-name@main
  - name: My backup step
    if: ${{ failure() }}
    uses: actions/heroku@1.0.0

runs.steps[*].name

          **省略可能** 複合ステップの名前。

runs.steps[*].id

          **省略可能** ステップの一意識別子。 
          `id` を使って、コンテキストのステップを参照することができます。 詳しくは、「[AUTOTITLE](/actions/learn-github-actions/contexts)」をご覧ください。

runs.steps[*].env

          **省略可能** そのステップのみの環境変数の `map` を設定します。 ワークフローに格納されている環境変数を変更する場合は、複合ステップで `echo "{name}={value}" >> $GITHUB_ENV` を使用します。

runs.steps[*].working-directory

          **省略可能** コマンドが実行される作業ディレクトリを指定します。

runs.steps[*].uses

          **省略可能** ジョブでステップの一部として実行されるアクションを選択します。 アクションとは、再利用可能なコードの単位です。 ワークフローと同じリポジトリ、パブリック リポジトリ、または[公開されている Docker コンテナー イメージ](https://hub.docker.com/)で定義されているアクションを使用できます。

Git ref、SHA、またはDockerタグ番号を指定して、使用しているアクションのバージョンを含めることを強く推奨します。 バージョンを指定しないと、アクションのオーナーがアップデートを公開したときに、ワークフローが中断したり、予期せぬ動作をしたりすることがあります。

  • リリースされたアクションバージョンのコミットSHAを使用するのが、安定性とセキュリティのうえで最も安全です。
  • 特定のメジャーアクションバージョンを使用すると、互換性を維持したまま重要な修正とセキュリティパッチを受け取ることができます。 ワークフローが引き続き動作することも保証できます。
  • アクションのデフォルトブランチを使用すると便利なこともありますが、別のユーザが破壊的変更を加えた新しいメジャーバージョンをリリースすると、ワークフローが動作しなくなる場合があります。

一部のアクションでは、with キーワードを使用して設定する必要がある入力が必要です。 必要な入力を判断するには、アクションのREADMEファイルをお読みください。

runs:
  using: "composite"
  steps:
    # Reference a specific commit
    - uses: actions/checkout@8f4b7f84864484a7bf31766abe9204da3cbe65b3
    # Reference the major version of a release
    - uses: actions/checkout@v5
    # Reference a specific version
    - uses: actions/checkout@v5.2.0
    # Reference a branch
    - uses: actions/checkout@main
    # References a subdirectory in a public GitHub repository at a specific branch, ref, or SHA
    - uses: actions/aws/ec2@main
    # References a local action
    - uses: ./.github/actions/my-action
    # References a docker public registry action
    - uses: docker://gcr.io/cloud-builders/gradle
    # Reference a docker image published on docker hub
    - uses: docker://alpine:3.8

runs.steps[*].with

省略可能 アクションによって定義された入力パラメーターの一部****。 各入力パラメータはキー/値ペアです。 詳しくは、「例: 入力の指定」をご覧ください。

runs:
  using: "composite"
  steps:
    - name: My first step
      uses: actions/hello_world@main
      with:
        first_name: Mona
        middle_name: The
        last_name: Octocat

runs.steps[*].continue-on-error

          **省略可能** ステップが失敗したときにアクションが失敗しないようにします。 
          `true` に設定すれば、このステップが失敗したときにアクションを成功させることができます。

Docker コンテナーのアクション runs

          **必須** Docker コンテナー アクションに使用されるイメージを構成します。

例: リポジトリでの Dockerfile の使用

runs:
  using: 'docker'
  image: 'Dockerfile'

例: パブリック Docker レジストリ コンテナーの使用

runs:
  using: 'docker'
  image: 'docker://debian:stretch-slim'

Docker コンテナーのアクション runs.using

          **必須** この値を `'docker'` に設定する必要があります。

runs.pre-entrypoint

          **省略可能**`entrypoint` アクションが開始される前にスクリプトを実行できます。 たとえば、`pre-entrypoint:` を使って必要なセットアップ スクリプトを実行できます。 GitHub Actions では `docker run` を使ってこのアクションを起動し、同じベース イメージを使用する新しいコンテナー内でスクリプトを実行します。 つまり、ランタイムの状態はメインの `entrypoint` コンテナーとは異なり、必要な状態はワークスペース、`HOME` で、または `STATE_` 変数としてアクセスされる必要があります。 
          `pre-entrypoint:` アクションは常に既定で実行されますが、[`runs.pre-if`](#runspre-if) を使用してこれをオーバーライドすることはできます。

          [
          `using`
          ](#runsusing-for-docker-container-actions) 構文で指定されたランタイムによりこのファイルが実行されます。

この例では、pre-entrypoint: アクションによって setup.sh というスクリプトが実行されます。

runs:
  using: 'docker'
  image: 'Dockerfile'
  args:
    - 'bzz'
  pre-entrypoint: 'setup.sh'
  entrypoint: 'main.sh'

runs.image

          **必須** アクションを実行するコンテナーとして使用する Docker イメージ。 値は、Docker のベース イメージ名、ご自分のリポジトリ内のローカル `Dockerfile`、または Docker Hub あるいは別のレジストリ内のパブリック イメージにすることができます。 ご自分のリポジトリにローカルな `Dockerfile` を参照するには、ファイルに `Dockerfile` という名前を付ける必要があり、アクション メタデータ ファイルに対する相対パスを使用する必要があります。 
          `docker` アプリケーションによってこのファイルが実行されます。

runs.env

          **省略可能** コンテナー環境で設定する環境変数のキー/値のマップを指定します。

runs.entrypoint

          **省略可能**`ENTRYPOINT` 内の Docker の `Dockerfile` を上書きするか、指定されていない場合は設定されます。 
          `entrypoint` で `Dockerfile` が指定されていない場合や、`ENTRYPOINT` 命令をオーバーライドする場合は `ENTRYPOINT` を使用します。 
          `entrypoint` を省略すると、Docker の `ENTRYPOINT` 命令で指定したコマンドが実行されます。 Docker の `ENTRYPOINT` 命令には、_shell_ 形式と _exec_ 形式があります。 Docker の `ENTRYPOINT` ドキュメントでは、_exec_ 形式の `ENTRYPOINT` 命令を使用することが推奨されています。

          `entrypoint` の実行の詳細については、「[AUTOTITLE](/actions/creating-actions/dockerfile-support-for-github-actions#entrypoint)」を参照してください。

runs.post-entrypoint

          **省略可能**`runs.entrypoint` アクションが完了したら、クリーンアップ スクリプトを実行できます。 GitHub Actions では `docker run` を使用して、このアクションを起動します。 GitHub Actions ではスクリプトを同じベース イメージを使って新しいコンテナー内で実行するため、ランタイムの状態はメインの `entrypoint` コンテナーとは異なります。 ワークスペース、`HOME` で、または `STATE_` 変数として必要な任意の状態にアクセスできます。 
          `post-entrypoint:` アクションは常に既定で実行されますが、[`runs.post-if`](#runspost-if) を使用してこれをオーバーライドすることはできます。

runs:
  using: 'docker'
  image: 'Dockerfile'
  args:
    - 'bzz'
  entrypoint: 'main.sh'
  post-entrypoint: 'cleanup.sh'

runs.args

          **省略可能** Docker コンテナーの入力を定義する文字列の配列。 入力には、ハードコードされた文字列を含めることができます。 GitHub により、コンテナーの起動時に `args` がコンテナーの`ENTRYPOINT` に渡されます。

          `args` は、`CMD` 内の `Dockerfile` 命令の代わりに使用されます。 ご自分の `CMD` で `Dockerfile` を使用する場合は、以下の優先順のガイドラインを使用してください。
  1. アクションの README 中で必須の引数をドキュメント化し、CMD 命令から除外します。
  2. args を指定せずにアクションを利用できるよう、既定値を使用します。
  3. アクションが --help フラグやそれに類するものを備えているなら、アクションを自己ドキュメント化するためにそれを利用します。

環境変数をアクションに渡す必要がある場合は、変数置換を行えるようアクションがコマンドシェルで実行されていることを確認してください。 たとえば、entrypoint 属性が "sh -c" に設定されている場合は、args がコマンド シェルで実行されます。 あるいは、Dockerfile で ENTRYPOINT を使用して同じコマンド ("sh -c") を実行する場合は、args がコマンド シェルで実行されます。

GitHub Actions での CMD 命令の使用の詳細については、「GitHub ActionsのためのDockerfileサポート」を参照してください。

例: Docker コンテナーの引数の定義

runs:
  using: 'docker'
  image: 'Dockerfile'
  args:
    - ${{ inputs.greeting }}
    - 'foo'
    - 'bar'

branding

          **省略可能**: アクションをパーソナライズして見分けられるようにするために、カラーと [Feather](https://feathericons.com/) アイコンを使ってバッジを作成することができます。 バッジは、[GitHub Marketplace](https://github.com/marketplace?type=actions) のアクション名の横に表示されます。

例: アクションのブランド化の構成

branding:
  icon: 'award'
  color: 'green'

branding.color

バッジの背景カラー。 white、black、yellow、blue、green、orange、red、purple、gray-dark のいずれかになります。

branding.icon

使用する v4.28.0 Feather アイコンの名前。

省略されたアイコン

ブランド アイコンと次のすべてのアイコンが省略されます。

  • コーヒー
  • 列
  • ディバイドサークル
  • 分割四角形
  • 除算
  • frown
  • 六角形
  • キー
  • まあまあ
  • マウスポインター
  • 微笑む
  • ツール
  • x-八角形

現在サポートされているすべてのアイコンの完全な一覧

  • アクティビティ
  • AirPlay
  • アラートサークル
  • アラート・オクタゴン
  • 警告トライアングル
  • align-center
  • align-justify
  • 左揃え
  • align-right
  • アンカー
  • 絞り
  • アーカイブ
  • 矢印下向き円
  • 下矢印左
  • 右下矢印
  • 下向き矢印
  • 左矢印サークル
  • 左向き矢印
  • 右矢印サークル
  • 右矢印
  • 上向き矢印円
  • 左上矢印
  • 右上矢印
  • 上向き矢印
  • アットマーク
  • アワード
  • 棒グラフ2
  • 棒グラフ
  • バッテリー充電
  • バッテリー
  • ベルオフ
  • ベル
  • Bluetooth
  • 太字
  • 本を開く
  • 本
  • ブックマーク
  • ボックス
  • ブリーフケース
  • カレンダー
  • カメラオフ
  • カメラ
  • キャスト
  • チェックサークル
  • チェックスクエア
  • 回
  • 下向きの矢印
  • chevron-left
  • 右矢印
  • シェブロンアップ
  • 下向きシェブロン
  • 左向きシェブロン
  • chevrons-right
  • 上向きの山形アイコン
  • circle
  • クリップボード
  • 時計
  • クラウド・ドリズル
  • クラウドライトニング
  • クラウドオフ
  • クラウド雨
  • クラウドスノー
  • クラウド
  • コード
  • コマンド
  • コンパス
  • コピー
  • 左下のコーナー
  • 右下コーナー
  • 左下の角
  • corner-left-up
  • 右下角
  • 右上隅への移動
  • 左上に曲がる
  • コーナーアップライト
  • cpu
  • クレジットカード
  • クロップする
  • クロスヘア
  • データベース
  • 削除する
  • ディスク
  • ドル記号
  • download-cloud
  • ダウンロード
  • droplet
  • 編集2
  • 編集-3
  • 編集
  • 外部リンク
  • 非表示
  • 目
  • 早送り
  • 羽
  • file-minus
  • ファイルプラス
  • ファイルテキスト
  • ファイル
  • 映画
  • フィルタ
  • フラグ
  • フォルダー減少
  • フォルダー追加
  • フォルダ
  • ギフト
  • git-branch
  • git-commit
  • git-merge
  • gitのプルリクエスト
  • 地球儀
  • グリッド
  • ハードディスク
  • ハッシュ
  • ヘッドホン
  • ハート
  • サポートアイコン
  • ホーム
  • イメージ
  • 受信箱
  • 情報
  • 斜体
  • レイヤー
  • レイアウト
  • life-buoy
  • link-2
  • リンク
  • リスト
  • ローダー
  • ロックする
  • ログイン
  • ログアウト
  • メール
  • マップ・ピン
  • マップ
  • 最大化-2
  • 最大化
  • メニュー
  • メッセージサークル
  • message-square
  • マイクオフ
  • マイク
  • 最小化-2
  • 最小化する
  • マイナス記号
  • マイナス四角形
  • マイナス
  • モニター
  • 月
  • より横向きの
  • さらに垂直
  • 移動
  • 音楽
  • navigation-2
  • ナビゲーション
  • 八角形
  • パッケージ
  • ゼムクリップ
  • pause-circle
  • 一時停止
  • パーセント
  • 電話通話
  • 電話転送
  • 電話-受信中
  • 不在着信
  • 電話オフ
  • 発信電話
  • 電話
  • 円グラフ
  • 再生サークル
  • 再生
  • プラスサークル
  • プラススクエア
  • プラス
  • ポケット
  • 電力
  • プリンタ
  • ラジオ
  • refresh-ccw
  • refresh-cw
  • 繰り返す
  • 巻き戻し
  • 反時計回りに回転
  • 時計回りに回転
  • rss
  • [保存]
  • はさみ
  • 検索
  • 送信
  • サーバー
  • 設定
  • share-2
  • 共有
  • シールドオフ
  • シールド
  • ショッピングバッグ
  • ショッピングカート
  • シャッフル
  • サイドバー
  • 巻き戻し機能
  • 次へスキップ
  • スラッシュ
  • スライダー
  • スマートフォン
  • スピーカー
  • 四角形
  • star
  • ストップサークル
  • 太陽
  • 日の出
  • 日没
  • テーブル
  • タブレット
  • タグ
  • ターゲット
  • ターミナル
  • 温度計
  • 低評価
  • いいね
  • 左に切り替える
  • 右に切り替え
  • ゴミ-2
  • ごみ箱
  • 下降トレンド
  • 上昇傾向
  • 三角形
  • トラック
  • テレビ
  • 型
  • 傘
  • 下線
  • ロックの解除
  • アップロードクラウド
  • アップロード
  • ユーザー確認
  • ユーザー削除
  • user-plus
  • user-x
  • ユーザー
  • ユーザー
  • ビデオオフ
  • ビデオ
  • ボイスメール
  • volume-1
  • volume-2
  • volume-x
  • ボリューム
  • ウォッチ式
  • WiFiオフ
  • wifi
  • 風
  • x-circle
  • x-square
  • x
  • ザップオフ
  • 消す
  • ズームイン
  • ズームアウト

メタデータ ファイル名を変更する

アクションのメタデータ ファイルは両方の YAML 形式をサポートしていますが、リリース間でメタデータ ファイル名を変更 (action.yml から action.yaml またはその逆) すると、GitHub Marketplace に公開されている以前のリリース バージョンに影響します。 ファイル名を変更すると、以前のファイル名に関連付けられているすべてのリリース バージョンが GitHub Marketplace に表示されなくなります。 以前のリリース バージョンには、ソース リポジトリを介してユーザーは引き続きアクセスできます。

新しいバージョンのアクションをリリースすると、メタデータ ファイル名の変更後にリリースされたバージョンのみが GitHub Marketplace タグを持ち、GitHub Marketplace に表示されます