Day 2 - GitHub Actions ရဲ့ အဓိက Concepts များနှင့် Runner အကြောင်း

ပြီးခဲ့တဲ့အပတ် Day 1 တုန်းက ကျွန်တော်တို့ CI/CD ရဲ့ Concept တွေကို အကြမ်းဖျင်း ပြောခဲ့ကြပြီးပြီနော်။

ဒီနေရာမှာ လက်တွေ့မစခင် ကြိုပြောချင်တာတစ်ခုက... CI/CD ဆိုတာ အဆင့်ကြီး နှစ်ခု ပေါင်းထားတာ ဖြစ်ပေမယ့် ကျွန်တော်တို့ အခြေခံ အုတ်မြစ် ခိုင်မာသွားအောင် လောလောဆယ်မှာတော့ CI (Continuous Integration) Flow အပိုင်းကိုပဲ တစိုက်မတ်မတ် အဓိကထားပြီး ရှင်းပြသွားမှာဖြစ်ပါတယ်။ ဒီ CI ပိုင်းကို ကောင်းကောင်း ပိုင်နိုင်သွားပြီး အားလုံး အဆင်သင့်ဖြစ်တဲ့ အခါမှ ပိုပြီး နက်နဲတဲ့ CD (Deployment) အပိုင်းကို တူတူ ဆက်သွားကြတာပေါ့။

ဒါကြောင့် ဒီတစ်ပတ်မှာတော့ တကယ့်လက်တွေ့ Pipeline တွေ မရေးခင် မဖြစ်မနေ သိရမယ့် GitHub Actions ရဲ့ အခြေခံ သဘောတရားတွေကို အသေးစိတ် ခွဲခြမ်းစိတ်ဖြာ ကြည့်ပါမယ်။

GitHub Actions ရဲ့ အားသာချက်က ကိုယ့် Project ရဲ့ Folder အောက်မှာ YAML ဖိုင်လေး တစ်ဖိုင် ရေးပေးလိုက်ရုံနဲ့တင် ရှုပ်ထွေးတဲ့ Automation အလုပ်တွေကို အလွယ်တကူ ခိုင်းစေနိုင်တာ ဖြစ်ပါတယ်။အဲဒီလို မခိုင်းခင်မှာ သူတို့ရဲ့ အဓိက အစိတ်အပိုင်း (Core Components) တွေကို အရင် သိထားဖို့ လိုပါတယ်။

ဥပမာအနေနဲ့ စဉ်းစားကြည့်ရအောင်ဗျာ-

ကျွန်တော်တို့က စားသောက်ဆိုင် တစ်ဆိုင် ဖွင့်ထားတယ်။ "ဆိုင်ထဲကို Customer ဝင်လာတိုင်း (Trigger)" ->

"စားဖိုဆောင်အဖွဲ့က ဟင်းချက်ရမယ် (Job 1)" နဲ့ "သန့်ရှင်းရေးအဖွဲ့က စားပွဲသုတ်ရမယ် (Job 2)" ဆိုပြီး ခိုင်းလိုက်တယ်။

စားဖိုဆောင်ဟင်းချက်တဲ့အဖွဲ့က

(Step 1) -> "Order ဖတ်မယ်"

(Step 2) -> "ဒယ်အိုး တည်မယ် "

(Action) အနေနဲ့ "ဟင်းခတ်အမွှေးအကြိုင် သုံးမယ်" ဆိုပြီး အဆင့်ဆင့် လုပ်သွားတာမျိုးပါ။

သန့်ရှင်းရေးအဖွဲ့ကလည်း

(Step 1) -> "စားပွဲဆီ လျှောက်သွားမယ်"

(Step 2) -> "စားပွဲပေါ်က ပန်းကန်တွေ သိမ်းမယ် "

(Action) အနေနဲ့ "ဆိုင်မှာ အဆင်သင့် ဆောင်ထားတဲ့ စက္ကူတစ်ရှူး သုံးမယ် " ဆိုပြီး လုပ်သွားတာမျိုးပါ။

ဒါကို Tech အခေါ်အဝေါ်တွေနဲ့ ပြန်ကြည့်ရအောင် -

• Trigger (Event) : Pipeline ကြီး စပြီး အလုပ်လုပ်အောင် လှုံ့ဆော်ပေးတဲ့ Event ဖြစ်ပါတယ်။ ဥပမာ- git push လုပ်လိုက်တာ၊ Pull Request ဆောက်လိုက်တာမျိုးပေါ့။

• Workflow : Trigger ဖြစ်လာရင် Run မယ့် Automated Process တစ်ခုလုံးကို ခြုံငုံပြီး Workflow လို့ ခေါ်ပါတယ်။ ဒီကောင်တွေကို .github/workflows/ ဆိုတဲ့ Folder အောက်မှာ .yml သို့မဟုတ် .yaml ဖိုင်တွေနဲ့ ရေးရပါတယ်။ ကိုယ့် project မှာ workflow ဖိုင်တွေ အများကြီး ခွဲရေးထားလို့ ရပါတယ်)

• Jobs : Workflow ကြီးတစ်ခုလုံး အလုပ်လုပ်ဖို့အတွက် Jobs တွေနဲ့ ဖွဲ့စည်းထားတာ ဖြစ်ပါတယ်။။ ဥပမာ- Test စစ်တဲ့အလုပ် (Test Job)၊ Build ဆွဲတဲ့အလုပ် (Build Job)။ အထူးခြားဆုံးက ဒီ Job တွေဟာ တစ်ပြိုင်နက်တည်း (Parallelly) အလုပ်လုပ်ကြတာ ဖြစ်ပါတယ်။

• Steps : Job တစ်ခုချင်းစီရဲ့ အတွင်းထဲမှာ ထပ်ပြီး ပါဝင်နေတာကတော့ Steps တွေ ဖြစ်ပါတယ်။ သူတို့ကတော့ Job တစ်ခုအတွင်းမှာ တစ်ဆင့်ချင်းစီ လုပ်သွားရမယ့် အလုပ်သေးလေးတွေပါ။ ဥပမာ- (Step 1) node environment ပြင်မယ် -> (Step 2) dependency တွေသွင်းမယ် -> (Step 3) test run မယ်။ ဒါကြောင့် သူကတော့ အပေါ်ကနေ အောက်ကို sequential (တစ်ဆင့်ပြီးမှ တစ်ဆင့်) တန်းစီပြီး အလုပ်လုပ်ပါတယ်။

• Actions : ဒါကတော့ Step တွေရဲ့ အတွင်းထဲမှာ တကယ့်လက်တွေ့ အလုပ်လုပ်ဖို့ ထည့်သုံးရတဲ့ ကောင်တွေ ဖြစ်ပါတယ်။ အလွယ်ဆုံး ပြောရရင်တော့ "သူများ အဆင်သင့် ရေးပေးထားတဲ့ Ready-made Commands တွေ" ပါပဲ။ "ငါ့ Code တွေကို GitHub ပေါ်ကနေ ဆွဲယူပေးပါ" လို့ ခိုင်းချင်တယ် ဆိုပါစို့။ အဲဒီအတွက် Command တွေ အရှည်ကြီး လိုက်ရေးနေစရာ မလိုပါဘူး။ GitHub Actions က ပေးထားတဲ့ Ready-made ကုဒ်လေးကို YAML ဖိုင်ထဲမှာ uses: ဆိုပြီး ဒီလိုလေး လှမ်းခေါ်သုံးလိုက်ရုံပါပဲ -

1- name: Check out repository code
2  uses: actions/checkout@v4

Workflow ရဲ့ တည်ဆောက်ပုံ Syntax (Structure)

YAML ဖိုင်ထဲမှာ သူတို့ကို ဘယ်လို အစီအစဉ်အတိုင်း ရေးလဲဆိုတာ အောက်က ပုံစံအတိုင်း အဆင့်ဆင့် သွားပါတယ် -

1name: [Workflow ရဲ့ နာမည်]
2 
3on:
4  [ဒီနေရာမှာ Trigger တွေကို သတ်မှတ်တယ်]
5 
6jobs:
7  [Job Name 1]:
8    runs-on: [ဘယ်စက်ပေါ်မှာ Run မလဲ]
9    steps:
10      - name: [Step Name 1]
11        uses: [အသင့်သုံး Action သုံးမလား]
12      - name: [Step Name 2]
13        run: [Command ရိုက်ပြီး ခိုင်းမလား]
14 
15  [Job Name 2]:
16    runs-on: [ဘယ်စက်ပေါ်မှာ Run မလဲ]
17    steps:
18      - name: [Step Name 1]
19        run: [Command အတို ရိုက်ခိုင်းတာမျိုး]

ကဲ... Concept တွေ ရှုပ်သွားရင် မျက်စိထဲ မြင်သာအောင် အရှင်းဆုံး Hello World ပြပေးမယ့် .yml ဖိုင်လေး တစ်ဖိုင် ရေးကြည့်ရအောင်ဗျာ။

1name: Day 2 Simple CI
2 
3#Trigger သတ်မှတ်ခြင်း - main branch ကို push တိုင်း အလုပ်လုပ်မယ်
4on:
5  push:
6    branches:
7      - main
8 
9#Jobs သတ်မှတ်ခြင်း
10jobs:
11  say-hello-job:
12    runs-on: ubuntu-latest  # ဘယ်စက်ပေါ်မှာ Run မလဲ (Runner ရွေးချယ်မှု)
13 
14#Steps (တစ်ဆင့်ချင်းစီ လုပ်မယ့်အလုပ်)
15    steps:
16      - name: Step One - Checkout Code
17        uses: actions/checkout@v4  #  Actions သုံးပြီး ကိုယ့် Code ကို စက်ထဲ ဆွဲထည့်တာ
18      - name: Step Two - Print Message
19        run: echo "Hello, GitHub Actions! Your CI is running successfully!"

GitHub-Hosted Runner ဆိုတာ ဘာကြီးလဲ?

ကျွန်တော်တို့က git push လိုက်လို့ GitHub Actions က အလုပ်လုပ်ပြီဆိုရင် ကျွန်တော်တို့ရဲ့ စမ်းသပ်တဲ့ Command တွေ၊ Build ဆွဲတဲ့ အလုပ်တွေကို ဘယ်သူက လာ run ပေးတာလဲ? ကျွန်တော်တို့ရဲ့ ကိုယ်ပိုင် Laptop က လုပ်ပေးတာ မဟုတ်ပါဘူး။

အဲဒီအလုပ်တွေကို နောက်ကွယ်မှာ အခမဲ့ လုပ်ပေးနေတာ GitHub-Hosted Runner တွေ ဖြစ်ပါတယ်။

သူ့ရဲ့ သဘောသဘာဝက ဒီလိုပါ -

• On-Demand VM (ယာယီ VMလေးတွေ): မင်းရဲ့ pipeline Trigger ဖြစ်တာနဲ့ GitHub က သူ့ရဲ့ Cloud ပေါ်မှာ Virtual Machine (VM) အသေးလေးတစ်လုံးကို ချက်ချင်း ဆောက်ပေးလိုက်တာ ဖြစ်ပါတယ်။

• OS Selection (Runnner ရွေးချယ်မှု): အပေါ်က code ထဲမှာ runs-on: ubuntu-latest လို့ ရေးထားတဲ့အတွက် GitHub က Ubuntu (Linux) စက်တစ်လုံးကို run ပေးလိုက်တာပါ။ ကိုယ့် Project အလိုက် Windows ဒါမှမဟုတ် macOS စက်တွေကိုလည်း စိတ်ကြိုက် တောင်းလို့ရပါတယ်။ (ဒါပေမယ့် Linux က အပေါ့ပါးဆုံးနဲ့ အမြန်ဆုံးမို့ အသုံးအများဆုံးပါ)

• Pre-installed Tools : ဒီစက်အသစ်လေးထဲမှာ ကျွန်တော်တို့အတွက် Git, Docker, Node.js, Python တို့လို အသုံးများတဲ့ tools တွေ အကုန်လုံးကို GitHub က ကြိုတင် သွင်းပေးထားပြီးသားမို့လို့ ဘာမှ လိုက်သွင်းနေစရာမလိုဘဲ အဆင်သင့် သုံးရုံပါပဲ။

• Episodic Environment (အလုပ်ပြီးရင် အလိုအလျောက် ပျက်စီးပါတယ်): ကျွန်တော်တို့ရဲ့ Workflow ကြီး လုပ်စရာရှိတာတွေ လုပ်လို့ပြီးသွားပြီ (သို့မဟုတ်) Error တက်ပြီး ရပ်သွားပြီဆိုတာနဲ့ အဲဒီ VM စက်ကလေးကို GitHub က အစအနမကျန် ဖျက်ပစ် (Destroy) လိုက်ပါတယ်။ နောက်တစ်ခါ ထပ် push ရင် စက်အသစ်တစ်လုံး ပြန် Run ပေးတာပါ။

သတိထားရမှာကတော့ စက်က အလုပ်ပြီးရင် ပျက်သွားမှာ ဖြစ်တဲ့အတွက် ကြားထဲမှာ ထွက်လာတဲ့ build ဖိုင်တွေကို သိမ်းချင်ရင် Artifact စနစ်သုံးပြီး လှမ်းသိမ်းဖို့ လိုအပ်တာ ဖြစ်ပါတယ်။ (ဒါကိုတော့ နောက်ပိုင်းမှ ဆက်ပြောပါမယ်)

ဒါဆို Self-Hosted Runner ဆိုတာရော ရှိသေးလား?

ရှိပါတယ်ဗျာ။ GitHub က ပေးတဲ့ Cloud စက်တွေကို မသုံးချင်ဘူး (သို့မဟုတ်) ကိုယ့်ကုမ္ပဏီမှာ ရှိပြီးသား ကိုယ်ပိုင် Server / ကွန်ပျူတာ ပေါ်မှာပဲ ဒီ Pipeline တွေကို Run ချင်တယ်ဆိုရင် အဲဒါကို Self-Hosted Runner လို့ ခေါ်ပါတယ်။

သူ့ရဲ့ ထူးခြားချက်တွေကတော့ -

• ကိုယ်ပိုင်စက်ကို အသုံးပြုခြင်း: ကိုယ့်ရုံးက ကွန်ပျူတာ၊ ဒါမှမဟုတ် AWS ပေါ်မှာ ဝယ်ထားတဲ့ EC2 Instance စတဲ့ စက်တွေထဲကို GitHub Actions Agent လေး သွင်းပြီး Runner အဖြစ် ပြောင်းလဲလိုက်တာပါ။

• Persistent Environment (မပျက်မစီး ဆက်ရှိနေခြင်း): GitHub-Hosted စက်တွေလို အလုပ်ပြီးရင် ပျက်မသွားပါဘူး။ ကိုယ့်စက်ဖြစ်လို့ အမြဲတမ်း ရှိနေပြီး file တွေ၊ cache တွေ အကုန် ကျန်နေခဲ့မှာပါ။

• Customization & Security: ကိုယ့်စက်ဖြစ်တဲ့အတွက် ကြိုက်တဲ့ Tools တွေ အားလုံးကို စိတ်ကြိုက် သွင်းထားလို့ရသလို၊ ကုမ္ပဏီရဲ့ Internal Network (Private Network) ထဲမှာပဲ သီးသန့် Run ချင်တဲ့ အခါမျိုးမှာ သုံးပါတယ်။

GitHub က အလကားပေးတဲ့ ယာယီစက်ကို သုံးရင် GitHub-Hosted၊ ကိုယ့် Server ထဲမှာ ကိုယ်တိုင် Setup လုပ်ပြီး သုံးရင် Self-Hosted လို့ မှတ်ထားလိုက်ရင် ရပါပြီဗျာ!

ဒီနေ့ Day 2 မှာတော့ GitHub Actions ရဲ့ အဓိက ဖြစ်တဲ့ Workflow, Jobs, Steps, Actions, Trigger အကြောင်းနဲ့ နောက်ကွယ်က Runner တွေ ဘယ်လို အလုပ်လုပ်လဲဆိုတာကို သိသွားလောက်ကြပြီ ဖြစ်မှာပါ။

နောက်တစ်ပတ် Day 3 မှာတော့ ဒီကောင်တွေကို သုံးပြီး တကယ့် Project တစ်ခုကို လက်တွေ့ စမ်းသပ်မယ့် Hands-on Lab ကို သွားတော့မှာမို့လို့ မျက်ခြေမပြတ် စောင့်ကြည့်ပေးကြပါဦးဗျာ!

Happy Coding!