Github Actionsのワークフローを作成する場合、onプロパティの値を使用してワークフローをトリガーするイベントを決定できます.このアクティビティのリストはActions Docs - events that trigger workflowsで見ることができますが、よく使われているものを整理したいと思います.

push

これは最も一般的なアクティビティになります.タグをコミットまたはプッシュすると、ワークフローが実行されます.ちなみに、Pushイベントには、開発者がgit pushコマンドを使用してPushを行うだけでなく、PRを停止したときにコミットを終了することも含まれます.

on:
  push

前述したように、すべてのブール値とタグに対してpushイベントが発生すると、この操作がトリガーされます.

Filter

特定のスパナまたは特定のラベルのみをトリガーしたい場合は、フィルタを使用します.pushアクティビティには、以下の6つのフィルタがあります.

branches

branches-ignore

tags

tags-ignore

paths

paths-ignore

branches & branches-ignore

# flow1.yml
on:
  push:
    branches:
      - main
      - mona/octocat
      - releases/**
 
 # flow2.yml
 on:
   push:
    branches-ignore: 
      - dev
      - releases/**-alpha 

branchesは、トリガに含まれる分岐路を決定する.branches-ignore逆に排除を決定したブレンチ.2つのフィルタは同時に使用できません.mainまたはmona/octocatdevのように、正しいbrunch名を書くことができます.この場合、同じbrenchを正確に含むか排除する.releases/**またはreleases/**-alphaのように、Glob Patternを使用して複数のパターンをマッチングすることもできる.この場合、パターンに一致するブレンチが含まれるか、または除外される.

on:
  push:
    branches:
      - releases/**
      - '!releases/**-alpha'

前述したように、branchesとbranches-ignoreを同時に使用することはできません.しかし、特定のPrefixを有するいくつかのブレンチを排除することが望ましいかもしれない.この場合、!を使用することができる.上記の例では、releases/で始まるbrenchを含むが、-alphaで終わるbrenchを除く.!を使用する場合は、!を使用していないスパナを少なくとも1つ定義する必要があります.上記の例から- releases/**文を削除すると、エラーが発生します.

tags & tags-ignore

# flow1.yml
on:
  push:
    tags:
      - releases-**
 
 # flow2.yml
 on:
   push:
    branches-ignore: 
      - test-**

tagsは、トリガに含めるタグを決定する.tags-ignoreは、逆に除外するタグを決定する.2つのフィルタは同時に使用できません.branches、branches-ignoreと同様に、正しいラベル名を記入したりglobモードを使用したりすることができます.同様に、!文を使用することもできます.

on:
  push:
    branches:
      - main
      - mona/octocat
      - releases/**
    tags:
      - releases-**

branchesシリーズのフィルターも上のように使えます.

paths & paths-ignore

# flow1.yml
on:
  push:
    paths:
      - '**.js'
 
 # flow2.yml
 on:
   push:
    paths-ignore: 
      - 'docs/**'

pathsおよびpaths-ignoreは、ブール値またはマーカーを操作するフィルタではない.このフィルタは、ファイルのパスを操作するフィルタです.前述したように、pathsを**.jsと定義すると、プロジェクトに含まれる.jsファイルが変更されると、ワークフローが実行されます.同様に、pathsとpaths-ignoreを同時に使用することはできず、!構文を使用することができる.
pathsシリーズのフィルターが上の写真のように動作していると理解できます.したがって、branchesまたはtagsフィルタとともに使用される場合、トリガするには、両方の要件を満たす必要がある.

pull_request

Pull Request、オープンまたはPRのHead Branch更新を開くとトリガーされます.ただし、Pull RequestでMerge Conflictが発生した場合、リクエストはトリガーされません.この場合、まずMergeConflictを解決します.

on:
  pull_request

pushの場合と同様に、フィルタを適用しない場合は、すべてのprを操作します.

Filter

特定のレンチだけをトリガしたい場合は、フィルタを使用します.pull requestイベントには、次の4つのフィルタがあります.

branches

branches-ignore

paths

paths-ignore

PRはマークに関係なく、tagsおよびtags-ignoreフィルタがない.残りの4つのフィルタの役割はPushイベントと同じです.

Activity Type

on:
  pull_request:
    types: [opened, reopened]

PRにはActivity Typeが複数あります.PRまたはReopen、Head Branch更新を開くとトリガーされます.このopened、reopened、synchronizeはアクティブタイプで、別途指定しない場合はデフォルトで上記3種類をトリガとして使用します.
上記の例に示すように、openedおよびreopendが指定されている場合、PRが再開されたときにのみトリガーされる.より多くのActivity Typeはevents that trigger workflow - pull_requestで確認できます.

workflow_dispatch

これは、ワークフローを手動で実行できるトリガです.このイベントを使用すると、Github Actionsページで手動でワークフローを実行できます.Github CLIまたはGithub APIを使用して実行することもできます.ただし、Githubに登録されているメインブラウザには、対応するワークフローファイルが必要です.

on: 
  workflow_dispatch

メインレンチに上のようにトリガをセットすると…
これにより、Actionsページでワークフローを手動で実行できます.
を運転するブルンジも選択できます.

inputs

workflow dispatchはinputsによってユーザに特定の値を提供することができる.

on:
  workflow_dispatch:
    inputs:
      logLevel:
        description: 'Log level'
        required: true
        default: 'warning'
        type: choice
        options:
        - info
        - warning
        - debug
      tags:
        description: 'Test scenario tags'
        required: false 
        type: boolean
      environment:
        description: 'Environment to run tests against'
        type: environment
        required: true 
      name:
        description: 'print name'
jobs:
  log-the-inputs:
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo "Log level: $LEVEL"
          echo "Tags: $TAGS"
          echo "Environment: $ENVIRONMENT"
          echo "hello ${{ github.event.inputs.hello }}"
        env:
          LEVEL: ${{ github.event.inputs.logLevel }}
          TAGS: ${{ github.event.inputs.tags }}
          ENVIRONMENT: ${{ github.event.inputs.environment }}

上記のように様々なタイプの入力を定義できます.入力値は${{ github.event.inputs.<<input_id>>とすることができる.
ビットのように値を入力できます.
入力値は、上記のようにワークフローで使用できます.
TMIが1つしか追加されていない場合、Booleanタイプは、BooleanではなくワークフローでStringとして表されます.すなわち、falseではなく'false'であり、trueではなく'true'の文字列である.使用時に注意して使用する.

workflow_run

他のワークフローの実行に関連付けられたイベント.指定したワークフローは、実行要求を受信または完了したときに実行されます.

# flow1.yml
name: Workflow Test
~~

# flow2.yml
name: Workflow Test2
on:
  workflow_run:
    workflows: [ Workflow Test ]

上記の場合、Workflow Testは、実行要求の受信時および実行完了時にWorkflow Test2を実行する.

on:
  workflow_run:
    workflows: [ Workflow Test, Lint Test ]

以上のように、複数のワークフローが指定されている場合、Workflow TestまたはLint Testのワークフローが実行されたときにトリガーされます.

# flow1.yml
name: flow1

# flow2.yml
name: flow2
on:
  workflow_run:
    workflows: [ flow1 ]

# flow3.yml
name: flow3
on:
  workflow_run:
    workflows: [ flow2 ]

上記の例に示すように、複数のワークフローを順次実行できます.ただし、これらのチェーンは最大3つまで接続できます.A -> B -> C -> D -> E -> FというChainがあれば、BからFまでworkflow_runを使うべきです.この場合、最初の3つのワークフローB、C、Dのみが実行され、E、Fは実行されません.

Filter

on:
  workflow_run:
    workflows: [Build]
    types: [requested]
    branches: [canary]

workflow runはFilterも使用できます.branchesとbranches-ignoreの2種類を使用できます.

Activity Type

Activity Typeには、上記の実行要求(requested)と正常終了(completed)の2種類があります.

on:
  workflow_run:
    workflows: [ Workflow Test ]
    types:
      - completed

以上のようにtypesプロパティとして指定できます.上記の例では、Workflow Testの動作が完了するとトリガーされる.
requestedタイプを参照してください.ワークフローがre-runの場合、トリガーされません.

on:
  workflow_run:
    workflows: [Build]
    types: [completed]

jobs:
  on-success:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    steps:
      - run: echo 'The triggering workflow passed'
  on-failure:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    steps:
      - run: echo 'The triggering workflow failed'

completedタイプには、通常の終了だけでなく、失敗またはキャンセルも含まれます.ただし、以前のワークフローが成功したときにのみ実行したい場合があります.この場合、github.event.workflow_run.conclusionプロパティを使用できます.
上記の例では、ジョブは、ifおよびgithub.event.workflow_run.conclusionを使用して、以前のワークフローの終了状態に従って実行するかどうかを制御する.

あわただしく

上にまとめた4つのイベントのほかにも、たくさんのイベントが存在します.しかし、上記の4点さえ分かれば、私たちが必要とする多くの状況に適用することができます.