Triggers: Workflow ဘယ်အချိန် Run မလဲ ဆုံးဖြတ်ခြင်း

နားလည်ထားရမယ့် အချက်

on: key က workflow ကို ဘယ်အခိုက်အတန့်မှာ run မလဲ ဆုံးဖြတ်ပေးပါတယ်။ အသုံးအများဆုံး လေးမျိုးက - push (commit တွေ branch တစ်ခုပေါ် ရောက်လာတိုင်း)၊ pull_request (PR ဖွင့်တာ၊ commit အသစ်တင်တာ၊ ပြန်ဖွင့်တာ)၊ schedule (cron expression နဲ့ အချိန်ဇယားအလိုက်၊ UTC အချိန်ဖြစ်ပါတယ်)၊ နဲ့ workflow_dispatch (Actions tab ကနေ လူကိုယ်တိုင် နှိပ်ပြီး run တာ) တို့ပါ။ event တစ်ခုစီမှာ filter တွေ ထည့်နိုင်ပါတယ်။ branches က ဘယ် branch တွေအတွက်လဲ ကန့်သတ်ပေးပြီး၊ paths နဲ့ paths-ignore က commit ထဲမှာ ဘယ် file တွေ ပါလာမှ run မလဲ ကန့်သတ်ပေးပါတယ်။

Path filter တွေဟာ အလှဆင်မှု မဟုတ်ပါဘူး - monorepo မှာ တကယ့် ငွေကြေး ကိစ္စပါ။ apps/web, apps/mobile, packages/api ရှိတဲ့ repo တစ်ခုမှာ README တစ်ကြောင်း ပြင်ရုံနဲ့ e2e suite တစ်ခုလုံး run နေရင် ကုန်ကျစရိတ်နဲ့ engineer တွေရဲ့ စောင့်ချိန် နှစ်ခုလုံး ဆုံးရှုံးပါတယ်။ paths: ['apps/web/**'] လိုမျိုး ထည့်လိုက်ရုံနဲ့ မဆိုင်တဲ့ run တွေ ပျောက်သွားပါတယ်။ သတိထားရမှာက required status check တစ်ခုကို path filter နဲ့ ကန့်သတ်ထားရင် အဲဒီ check က မ run တဲ့အခါ PR က "expected" အဆင့်မှာ ထာဝရ ငေးနေတတ်ပါတယ်။

နောက်ဆုံးအချက်က အရေးအကြီးဆုံးပါ။ pull_request event က သင့် branch ရဲ့ နောက်ဆုံး commit ပေါ်မှာ တိုက်ရိုက် run တာ မဟုတ်ပါဘူး။ GitHub က သင့် branch ကို base branch (များသောအားဖြင့် main) နဲ့ ပေါင်းထားတဲ့ ယာယီ merge commit တစ်ခု ဆောက်ပြီး အဲဒါပေါ်မှာ run ပါတယ်။ ဒါက အလွန်ကောင်းတဲ့ အလုပ်ပါ - merge ပြီးရင် ဘယ်လိုဖြစ်မလဲဆိုတာကို ကြိုစစ်ပေးလို့ပါ။ ဒါပေမယ့် အံ့အားသင့်စရာ နှစ်ခု ပါလာပါတယ် - github.sha က သင့် commit မဟုတ်ဘဲ merge commit ရဲ့ sha ဖြစ်နေတယ် (သင့်ဟာက github.event.pull_request.head.sha ပါ)၊ ပြီးတော့ ကိုယ့် branch မှာ ဘာမှ မပြင်ဘဲနဲ့ main က ပြောင်းသွားလို့ CI ကျရှုံးသွားနိုင်ပါတယ်။ ဒါဟာ bug မဟုတ်ဘဲ ရည်ရွယ်ချက်ရှိရှိ ဒီဇိုင်းဆွဲထားတာပါ။

EVENTS THROUGH FILTER GATES INTO WORKFLOWS
------------------------------------------
  EVENT                  FILTER GATE               RESULT
  ------------------     -------------------       --------------
  push to main       --> [ branches: main ]    --> deploy.yml runs
  push to feat/login --> [ branches: main ]    --X no run
  PR touching web/   --> [ paths: web/** ]     --> ci.yml runs
  PR touching docs/  --> [ paths: web/** ]     --X no run
  cron 0 3 * * 1     --> [ no filter ]         --> nightly.yml runs
  manual button      --> [ workflow_dispatch ] --> release.yml runs


  WHAT pull_request ACTUALLY CHECKS OUT

     your branch head            base branch (main)
     +----------------+          +----------------+
     |  commit abc123 |          |  commit 9f8e7d |
     +----------------+          +----------------+
              |                          |
              +------------+-------------+
                           v
              +-----------------------------+
              | temporary MERGE COMMIT      |  <-- CI runs here
              | github.sha points to THIS   |
              +-----------------------------+

  your own commit is at: github.event.pull_request.head.sha

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

အောက်က workflow မှာ trigger လေးမျိုးလုံး ပါဝင်ပါတယ်။ push အပိုင်းမှာ branches နဲ့ paths နှစ်ခုလုံး ရှိပါတယ် - နှစ်ခုစလုံး ကိုက်မှသာ run ပါတယ်။ ဆိုလိုတာက main ပေါ်ကို push လုပ်ပေမယ့် apps/web/ အောက်မှာ ဘာမှ မပြောင်းရင် workflow က မ run ပါဘူး။ .github/workflows/** ကို paths ထဲ ထည့်ထားတာက အရေးကြီးပါတယ် - workflow ကိုယ်တိုင်ကို ပြင်တဲ့အခါ အဲဒီ ပြင်ဆင်မှုက အလုပ်လုပ်မလုပ် ချက်ချင်း သိရဖို့ပါ။

pull_request မှာတော့ paths-ignore နဲ့ '**.md' ကို ချန်ထားလိုက်ပါတယ် - documentation သက်သက် ပြင်တဲ့ PR တွေအတွက် CI ကို မ run တော့ပါဘူး။ schedule က cron '0 3 * * 1' ဖြစ်လို့ တနင်္လာနေ့တိုင်း UTC နံနက် ၃ နာရီမှာ run ပါတယ်။ ဒါက local time မဟုတ်ဘူးဆိုတာ သတိထားပါ - မြန်မာစံတော်ချိန်နဲ့ဆို မွန်းလွဲ ၉:၃၀ ဖြစ်ပါတယ်။

workflow_dispatch မှာ environment ဆိုတဲ့ choice input ထည့်ထားပါတယ်။ ဒါကြောင့် Actions tab မှာ Run workflow ကို နှိပ်တဲ့အခါ staging ဒါမှမဟုတ် production ကို ရွေးလို့ရတဲ့ dropdown ပေါ်လာပါတယ်၊ အဲဒီတန်ဖိုးကို ${{ inputs.environment }} နဲ့ ဖတ်နိုင်ပါတယ်။ dispatch မဟုတ်တဲ့ run တွေမှာ ဒီတန်ဖိုးက ဗလာ ဖြစ်နေမှာမို့ လက်တွေ့မှာ ${{ inputs.environment || 'staging' }} လိုမျိုး fallback ပေးလေ့ရှိပါတယ်။

• push, pull_request, schedule, workflow_dispatch
• branch + path filter က မလိုအပ်တဲ့ run တွေကို ဖြတ်ပေးတယ်
• pull_request က merge commit ပေါ်မှာ run တယ်

အတူတူ စမ်းရေးကြည့်မယ်

name: Triggers

on:
  push:
    branches:
      - main
      - 'release/**'
    paths:
      - 'apps/web/**'
      - '.github/workflows/**'
  pull_request:
    branches: [main]
    paths-ignore:
      - '**.md'
      - 'docs/**'
  schedule:
    - cron: '0 3 * * 1'
  workflow_dispatch:
    inputs:
      environment:
        description: Which environment to target
        type: choice
        default: staging
        options:
          - staging
          - production

jobs:
  report:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Show what triggered this run
        run: |
          echo "event:  ${{ github.event_name }}"
          echo "ref:    ${{ github.ref }}"
          echo "sha:    ${{ github.sha }}"
          echo "target: ${{ inputs.environment || 'staging' }}"

ဒီ workflow က အခြေအနေ လေးမျိုးမှာ run ပါတယ် - main သို့မဟုတ် release/* branch ပေါ်ကို push လုပ်ပြီး apps/web/ သို့မဟုတ် .github/workflows/ အောက်က file တစ်ခုခု ပါလာမှ၊ main ကို target ထားတဲ့ pull_request ဖွင့်/update လုပ်ပြီး .md နဲ့ docs/ ချည်းသက်သက် မဟုတ်မှ၊ တနင်္လာနေ့တိုင်း UTC ၀၃:၀၀ မှာ၊ ဒါမှမဟုတ် Actions tab က Run workflow ခလုတ်ကို လူကိုယ်တိုင် နှိပ်တဲ့အခါပါ။ ဘယ်အခြေအနေမှာမဆို report job တစ်ခုတည်းသာ run ပြီး trigger အချက်အလက်တွေကို log ထဲ echo လုပ်ပါတယ်။ push run မှာ github.sha က push လုပ်လိုက်တဲ့ commit ဖြစ်ပြီး၊ pull_request run မှာတော့ GitHub ဆောက်ပေးထားတဲ့ ယာယီ merge commit ရဲ့ sha ဖြစ်ပါတယ်။ manual run မှ မဟုတ်ရင် inputs.environment က ဗလာဖြစ်လို့ fallback တန်ဖိုး staging ကို ပြပါတယ်။

GitHub Docs - Events that trigger workflows — CI/CD with GitHub Actions