プッシュでは実行されません。マッチする場合にワークフローを実行するように設定できます。タグへのプッシュに対して、パスのフィルタは評価されません。パターンを受け付けます。詳しい情報については、「フィルタパターンのチートシート」を参照してください。パターンとマッチする場合は常に、ワークフローは実行されません。定義されているパターンを、パス名に対して評価します。docsディレクトリ外のファイルを少なくとも1つ含むpushイベントでのみ実行されます。'docs/**'パスを含む例pathsフィルタのパターンにマッチするパスが1つでもあれば、ワークフローは実行されます。JavaScriptファイルをプッシュしたときにビルドを走らせるには、ワイルドカードパターンが使えます。'**.js'パスの除外パスは、2種類のフィルタで除外できます。これらのフィルタをワークフロー内の同じイベントで両方使うことはできません。パス名を除外する必要だけがある場合にはpaths-ignoreフィルタを使ってください。肯定のマッチのパスとパスの除外のフィルタが必要な場合はpathsフィルタを使ってください。肯定と否定のパターンを使用する例!文字を使って、pathsを除外できます。パターンを定義する順序により、結果に違いが生じます:肯定のマッチの後に否定のマッチングパターン(!がプレフィックスされている)を置くと、パスが除外されます。否定のマッチングパターンの後に肯定のマッチングパターンを定義すると、パスを再び含めます。この例は、pushイベントにsub-projectディレクトリあるいはそのサブディレクトリ内のファイルが含まれ、そのファイルがsub-project/docsディレクトリ内にあるのでない場合に実行されます。sub-project/index.jsもしくはsub-project/src/index.jsを変更するプッシュはワークフローを実行させますが、sub-project/docs/readme.mdだけを変更するプッシュは実行させません。1,000以上のコミットをプッシュする場合、あるいはGitHubがタイムアウトのためにdiffを生成できない(あまりにdiffが大きい)場合、そのワークフローは常に実行されます。フィルタは、変更されたファイルをpaths-ignoreあるいはpathsリストに対して評価することによって、ワークフローを実行すべきか判断します。ファイルが変更されていない場合、ワークフローは実行されません。GitHubはプッシュに対してはツードットdiff、プルリクエストに対してはスリードットdiffを使って変更されたファイルのリストを生成します。スリードットdiffは、トピックブランチの最新バージョンとトピックブランチがベースブランチと最後に同期されたコミットとの比較です。ツードットdiffは、headとベースのSHAを互いに直接比較します。深いプッシュの先祖の親に対するツードットdiffです。詳しい情報については「プルリクエスト中のブランチの比較について」を参照してください。時間にワークフローを実行できるようスケジュール設定できます。スケジュールしたワークフローは、デフォルトまたはベースブランチの直近のコミットで実行されます。スケジュールされたワークフローを実行できる最短のインターバルは5分ごとです。以下の例では、15分ごとにワークフローを実行します。*'cron構文に関する詳しい情報については、「ワークフローをトリガーするイベント」を参照してください。envワークフロー中のすべてのジョブやステップから利用できる環境変数のmapです。1つのジョブあるいはステップからだけ利用できる環境変数を設定することもできます。詳しい情報については「jobs.<job_id>.env」及び「jobs.<job_id>.steps.envを参照してください。同じ名前で複数の環境変数が定義されている場合、GitHubは最も具体的な環境変数を使用します。ステップ中で定義された環境変数は、ジョブやワークフローの同じ名前の変数をステップの実行の間オーバーライドします。ジョブで定義された変数は、そのジョブの実行の間はワークフローで定義された同じ名前の変数をオーバーライドします。jobs1つのワークフロー実行は、1つ以上のジョブからなります。デフォルトでは、ジョブは並行して実行されます。ジョブを逐次的に実行するには、jobs.<job_id>.needsキーワードを使用して他のジョブに対する依存関係を定義します。それぞれのジョブは、runs-onで指定された環境で実行されます。ワークフローの利用限度内であれば、実行するジョブ数に限度はありません。詳細については「利用限度」を参照してください。jobs.<job_id>各ジョブには、対応するIDがあります。job_idキーは文字列型で、その値はジョブの設定データのマップとなるものです。<job_id>は、jobsオブジェクトごとに一意の文字列に置き換える必要があります。<job_id>は、英字または_で始める必要があり、英数字と-、_しか使用できません。jobjobs.<job_id>.nameGitHubに表示されるジョブの名前。jobs.<job_id>.needsこのジョブの実行前に正常に完了する必要があるジョブを示します。文字列型または文字列の配列です。1つのジョブが失敗した場合、失敗したジョブを続行するような条件文を使用していない限り、そのジョブを必要としている他のジョブはすべてスキップされます。job2]この例では、job1が正常に完了してからjob2が始まり、job3はjob1とjob2が完了するまで待機します。この例のジョブは逐次実行されるということです。ジョブを実行するマシンの種類。マシンはGitHubホストランナーあるいは自己ホストランナーのいずれかです。GitHubホストランナーGitHubホストランナーを使う場合、それぞれのジョブはruns-onで指定された仮想環境の新しいインスタンスで実行されます。利用可能なGitHubホストランナーの種類は以下のとおりです。ubuntu-latest詳しい情報については「GitHubホストランナーの仮想環境」を参照してください。自己ホストランナージョブでセルフホストランナーを指定するには、ワークフローファイル中でセルフホストランナーのラベルでruns-onを設定してください。すべてのセルフホストランナーはself-hostedラベルを持ち、self-hostedラベルだけを提供すれば任意のセルフホストランナーを選択できます。特定のオペレーティングシステムやシステムアーキテクチャのラベルといった追加のラベルと合わせて配列中でself-hostedを使い、指定した種類のランナーだけを選択することもできます。linux]詳しい情報については「自己ホストランナーについて」及び「ワークフロー内での自己ホストランナーの利用」を参照してください。jobs.<job_id>.envジョブ中のすべてのステップから利用できる環境変数のmapです。ワークフロー全体あるいは個別のステップのための環境変数を設定することもできます。詳しい情報については「env」及び「jobs.<job_id>.steps.env」を参照してください。同じ名前で複数の環境変数が定義されている場合、GitHubは最も具体的な環境変数を使用します。ステップ中で定義された環境変数は、ジョブやワークフローの同じ名前の変数をステップの実行の間オーバーライドします。ジョブで定義された変数は、そのジョブの実行の間はワークフローで定義された同じ名前の変数をオーバーライドします。Monajobs.<job_id>.if条件文のifを使って、条件が満たされなければジョブを実行しないようにできます。条件文を作成するには、サポートされている任意のコンテキストや式が使えます。コンテキストと式構文」を参照してください。呼ばれる一連のタスクがあります。ステップでは、コマンドを実行する、設定タスクを実行する、あるいはリポジトリやパブリックリポジトリ、Dockerレジストリで公開されたアクションを実行することができます。すべてのステップでアクションを実行するとは限りませんが、すべてのアクションはステップとして実行されます。各ステップは、ランナー環境のそれ自体のプロセスで実行され、ワークスペースとファイルシステムにアクセスします。ステップはそれ自体のプロセスで実行されるため、環境変数を変更しても、ステップ間では反映されません。GitHubには、ジョブを設定して完了するステップが組み込まれています。ワークフローの利用限度内であれば、実行するステップ数に限度はありません。詳細については「利用限度」を参照してください。$LAST_NAME.jobs.<job_id>.steps.idステップの一意の識別子。idを使って、コンテキストのステップを参照することができます。コンテキストと式構文」を参照してください。jobs.<job_id>.steps.if条件文のifを使って、条件が満たされなければステップを実行しないようにできます。条件文を作成するには、サポートされている任意のコンテキストや式が使えます。コンテキストと式構文」を参照してください。コンテキストの使用例このステップは、イベントの種類がpull_requestでイベントアクションがunassignedの場合にのみ実行されます。stepは、ジョブの前のステップが失敗した場合にのみ実行されます。コンテキストと式構文」を参照してください。actions/heroku@masterjobs.<job_id>.steps.nameGitHubで表示されるステップの名前。jobs.<job_id>.steps.usesジョブでステップの一部として実行されるアクションを選択します。アクションとは、再利用可能なコードの単位です。ワークフロー、パブリックリポジトリ、または公開されているDockerコンテナイメージと同じリポジトリで定義されているアクションを使用できます。ref、SHA、またはDockerタグ番号を指定して、使用しているアクションのバージョンを含めることを強く推奨します。バージョンを指定しないと、アクションのオーナーがアップデートを公開したときに、ワークフローが中断したり、予期せぬ動作をしたりすることがあります。リリースされたアクションバージョンのコミットSHAを使用するのが、安定性とセキュリティのうえで最も安全です。特定のメジャーアクションバージョンを使用すると、互換性を維持したまま重要な修正とセキュリティパッチを受け取ることができます。ワークフローがまだ動作していることも確認できます。アクションのmasterブランチを使用すると便利なこともありますが、別のユーザーが大きな変更のある新しいメジャーバージョンをリリースすると、ワークフローが中断する場合があります。入力が必要なアクションもあり、入力をwithキーワードを使って設定する必要があります。必要な入力を判断するには、アクションのREADMEファイルをお読みください。アクションは、JavaScriptのファイルもしくはDockerコンテナです。使用するアクションがDockerコンテナの場合は、Linux環境で実行する必要があります。詳細についてはruns-onを参照してください。branchパブリックアクションを使用する例{owner}/{repo}@{ref}パブリックGitHubリポジトリのブランチ、ref、SHAを指定できます。actions/aws@v2.0.1サブディレクトリのパブリックアクションを使用する例{owner}/{repo}/{path}@{ref}パブリックGitHubリポジトリで特定のブランチ、ref、SHAにあるサブディレクトリ。actions/aws/ec2@masterワークフローと同じリポジトリにあるアクションを使用する例./path/to/dirワークフローのリポジトリにあるアクションを含むディレクトリのパス。Hubで公開されているDockerイメージ。docker://alpine:3.8Dockerパブリックレジストリアクションを使用する例docker://{host}/{image}:{tag}パブリックレジストリのDockerイメージ。docker://gcr.io/cloud-builders/gradlejobs.<job_id>.steps.runオペレーティングシステムのシェルを使用してコマンドラインプログラムを実行します。nameを指定しない場合、ステップ名はデフォルトでrunコマンドで指定された文字列になります。コマンドは、デフォルトでは非ログインシェルを使用して実行されます。別のシェルを選択して、コマンドを実行するシェルをカスタマイズできます。詳しい情報については「特定のシェルの利用」を参照してください。runキーワードは、それぞれがランナー環境での新しいプロセスとシェルです。複数行のコマンドを指定すると、各行が同じシェルで実行されます。buildworking-directoryキーワードを使えば、コマンドが実行されるワーキングディレクトリを指定できます。./temp特定のシェルを使用するshellキーワードを使用して、ランナーのオペレーティングシステムのデフォルトシェルを上書きできます。組み込みのshellキーワードを使用するか、カスタムセットのシェルオプションを定義することができます。非Windowsプラットフォームのデフォルトシェルで、shへのフォールバックがあります。Windowsでbashシェルを指定すると、Windows用Gitに含まれるbashシェルが使用されます。GitHubはスクリプト名に拡張子.ps1を追加します。Pythonのコマンドを実行します。非Windowsプラットフォームにおいてシェルが提供されておらず、パス上でbashが見つからなかった場合のフォールバック動作です。GitHubはスクリプト名に拡張子.cmdを追加し、{0}を置き換えます。これはWindowsで使われるデフォルトのシェルです。デスクトップPowerShellです。GitHubはスクリプト名に拡張子.ps1を追加します。[..more_options]を使用すると、テンプレート文字列にshell値を設定できます。GitHubは、空白区切りで最初の文字列をコマンドとして解釈し、{0}にある一時的なスクリプトのファイル名を挿入します。組み込みのshellキーワードについては、GitHubがホストする実行環境で以下のデフォルトが提供されます。シェルスクリプトを実行する際には、以下のガイドラインを使ってください。bashのデフォルトで、組み込みのshell。Windows以外のプラットフォームでオプションを指定しない場合のデフォルトでもあります。フェイルファーストをオプトアウトし、シェルのオプションにテンプレート文字列を指定して完全に制御することもできます。shライクのシェルは、スクリプトで実行された最後のコマンドの終了コードで終了します。これが、アクションのデフォルトの動作でもあります。runnerは、この終了コードに基づいてステップのステータスを失敗/成功としてレポートします。powershell/pwsh可能な場合のフェイルファースト動作。