ကျွန်ုပ်တို့ရဲ့ ယခင်ပို့စ်မှာ၊ တိုက်ရိုက်အဆိပ်သင့်ခြင်းကို ဘယ်လိုရှာဖွေပြီး ကာကွယ်ရမလဲဆိုတာ ကျွန်တော်တို့ မြင်တွေ့ခဲ့ရပါတယ် Pipeline အကောင်အထည်ဖော်မှု (D-PPE)။ ထိုအားနည်းချက်ကို မည်သို့ရှာဖွေရမည်ကိုလည်း ကျွန်ုပ်တို့တွေ့မြင်ခဲ့ရသည် Xygeni စကင်နာထို့အပြင် ကာကွယ်ရေးယန္တရားအချို့လည်း ပါဝင်သည်။
အဆိပ် Pipeline အကောင်အထည်ဖော်ခြင်း (PPE) ကို တိုက်ခိုက်သူက ပြုပြင်မွမ်းမံနိုင်သည့်အခါ ထုတ်လုပ်သည်။ pipeline ယုတ္တိဗေဒကို နည်းလမ်းနှစ်ခုထဲက တစ်ခုခုနဲ့
- CI config ဖိုင်ကို ပြုပြင်ခြင်းဖြင့် (the pipeline) -> တိုက်ရိုက် PPE (D-PPE)
- ရည်ညွှန်းထားသော ဖိုင်များကို ပြုပြင်ခြင်းဖြင့် pipeline (ဥပမာ- အတွင်းမှ ရည်ညွှန်းထားသော script များ pipeline ဖွဲ့စည်းမှုဖိုင်) -> သွယ်ဝိုက်သော PPE (I-PPE)
ဒီပို့စ်မှာ Indirect PPE အကြောင်း နက်နက်နဲနဲ ဆွေးနွေးပါမယ်။ ဒါပေမယ့် အဲဒါမတိုင်ခင်နဲ့ ကျွန်တော့်ရဲ့ ယခင်ပို့စ်ရဲ့ ဖြည့်စွက်အနေနဲ့ GitHub က ဘယ်လို execution တွေကို စီမံခန့်ခွဲလဲဆိုတာ အရင်ကြည့်ရအောင်။ pipelineပြီးတော့ D-PPE ကို ကာကွယ်တဲ့ ယန္တရားတွေက ဘာတွေလဲ။
GitHub က ဘယ်လို အကောင်အထည်ဖော်မှုကို ကာကွယ်ပေးသလဲ pipelinePR တွေဆီက လာတာလား?
ပြုပြင်ထားသော လုပ်ဆောင်ချက်နှင့် ပတ်သက်၍ GitHub သည် မည်သို့အလုပ်လုပ်သနည်း။ pipelines?
ပြုပြင်ထားသော pipelines များသည် Push များမှ လာနိုင်သည် သို့မဟုတ် Pull Requests (ပီအာရ်)။ အဓိက အကောင်းဆုံးလုပ်ဆောင်မှုတစ်ခုအနေဖြင့်၊ ကာကွယ်ထားသော ဌာနခွဲသို့ တိုက်ရိုက် “တွန်းပို့” ခြင်းနှင့် အသုံးပြုခြင်းတို့ကို ရှောင်ကြဉ်ရန် အထူးအကြံပြုလိုပါသည်။ Pull Requests ပံ့ပိုးထားသော ကုဒ်တစ်ခုခုကို လက်မခံမီ ပြန်လည်သုံးသပ်ချက်အချို့ကို ပြဋ္ဌာန်းရန် ယန္တရားတစ်ခုအဖြစ်။
Pull Requests အရင်းအမြစ်နှစ်ခုမှ ရောက်ရှိလာနိုင်သည်-
- PR များမှ လာပါသည် ချိတ်
- PR များမှ လာပါသည် အကိုင်းအခက်
PR များမှ ချိတ် ကနေ ဖြစ်ဖြစ် လာနိုင်ပါတယ် အများပြည်သူ or ကိုယ်ပိုင် repositories ။
PPE (အဆိပ်သင့်) နဲ့ ဆက်ဆံနေရတဲ့အချိန်မှာ Pipeline (အကောင်အထည်ဖော်ခြင်း)၊ ကျွန်ုပ်တို့၏ အဓိကအချက်မှာ PR ကို “လက်ခံခြင်း” မဟုတ်ဘဲ ပြုပြင်ထားသော pipeline PR ၏ လက်ခံမှု/အတည်ပြုချက် လုပ်ငန်းစဉ်အတွင်း။ PPE တိုက်ခိုက်မှု၏ အဓိကအချက်တွင်၊ “အန္တရာယ်ရှိသော” ပြုပြင်ထားသော pipeline.
စကားအနည်းငယ်ပြောရရင် အဆိပ်သင့်သွားတယ် Pipeline အကောင်အထည်ဖော်မှု (PPE) ကို ထုတ်လုပ်သည့်အခါ တိုက်ခိုက်သူသည် ပြုပြင်နိုင်သည် pipeline တက္ဏဗေဒ.
နှစ်ခုရှိတယ် မျိုးကွဲ:
- တိုက်ရိုက် PPE (D-PPED-PPE အခြေအနေမှာ တိုက်ခိုက်သူသည် CI config ဖိုင်ကို ပြုပြင်မွမ်းမံသည်။ repository တစ်ခုမှာ သူတို့ဝင်ရောက်ခွင့်ရှိပါတယ်၊ repo ပေါ်က အကာအကွယ်မဲ့ remote branch ကို ပြောင်းလဲမှုကို တိုက်ရိုက် push လုပ်ခြင်းအားဖြင့်ဖြစ်စေ၊ branch ဒါမှမဟုတ် fork ကနေ ပြောင်းလဲမှုနဲ့အတူ PR ကို submit လုပ်ခြင်းအားဖြင့်ဖြစ်စေ။ CI ကတည်းက pipeline ပြုပြင်ထားသော CI configuration ဖိုင်ရှိ command များဖြင့် execution ကို သတ်မှတ်ပြီး၊ attacker ၏ malicious command များသည် build node တွင် နောက်ဆုံးတွင် run ပါသည်။ pipeline လှုံ့ဆော်ပေးပါသည်။
- သွယ်ဝိုက်သော PPE (I-PPE): အချို့သောကိစ္စများတွင်၊ D-PPE ဖြစ်နိုင်ခြေကို ဝင်ရောက်ခွင့်ရှိသော ရန်သူအတွက် မရရှိနိုင်ပါ။ SCM သိုလှောင်ရုံ (ဥပမာ အကယ်၍ pipeline တူညီသော repository ရှိ သီးခြား၊ ကာကွယ်ထားသော branch တစ်ခုမှ CI configuration file ကို ဆွဲယူရန် configure လုပ်ထားသည်)။ ဒီလိုအခြေအနေမျိုးမှာ အဆိပ်ခတ်မယ့်အစား pipeline တိုက်ခိုက်သူသည် ၎င်းကိုယ်တိုင်က ရည်ညွှန်းထားသော ဖိုင်များထဲသို့ အန္တရာယ်ရှိသော ကုဒ်ကို ထိုးသွင်းသည် pipeline (ဥပမာ- အတွင်းမှ ရည်ညွှန်းထားသော script များ pipeline ဖွဲ့စည်းပုံဖိုင်)
ဖြစ်ရပ်နှစ်ခုလုံးတွင် GitHub သည် ပြုပြင်ထားသောအရာကို လုပ်ဆောင်ပါမည် pipeline ယခင်ပြန်လည်သုံးသပ်ချက် သို့မဟုတ် အတည်ပြုချက် မလိုအပ်ဘဲ.
PR များ forks မှစတင်၍ အများပြည်သူ အနားယူ
GitHub သည် လုပ်ဆောင်သည့်အခါ အပြုအမူကို ပြင်ဆင်သတ်မှတ်ခွင့်ပြုသည် public repos များရှိ forks များမှ PR များ ထွက်ပေါ်လာခြင်း.
PR တစ်ခုဟာ fork ကနေ လာနေတဲ့အခါ၊ GitHub ဟာ execute မလုပ်ခင်မှာ “approval” အဆင့်တစ်ခုကို အမြဲတမ်း အတင်းအကျပ် လုပ်ပါတယ်။ pipeline PR နဲ့ ဆက်စပ်နေတဲ့ဤထောက်ခံမှုအဆင့်သည် အားနည်းသောထောက်ခံမှုမှ တင်းကျပ်သောထောက်ခံမှုသို့ ပြောင်းလဲသွားပါသည်။
At အဖွဲ့အစည်းအဆင့် (Org>>Settings>>Actions>>General)၊ “အတည်ပြုချက်” ရွေးချယ်စရာများစွာထဲမှ သင်ရွေးချယ်နိုင်သည်-
အတင်းကျပ်ဆုံးကတော့ နောက်ဆုံးတစ်ခုပါ (“ပြင်ပပူးပေါင်းဆောင်ရွက်သူအားလုံးထံမှ ခွင့်ပြုချက်လိုအပ်သည်”)၊ အဘယ်ကြောင့်ဆိုသော် GitHub သည် ပြင်ပပူးပေါင်းဆောင်ရွက်သူများထံမှ forks များထံမှ PR လာသည့်အခါ အမြဲတမ်း ခွင့်ပြုချက် လိုအပ်မည်ဖြစ်သောကြောင့်ဖြစ်သည်။
ဒါပေမယ့် ဒီလို တင်းကျပ်တဲ့ကိစ္စမှာတောင် ဖတ်ရှုခွင့်နှင့် ရေးသားခွင့်ရှိသော ပူးပေါင်းဆောင်ရွက်သူများအကြား ကွာခြားချက်များ.
- PR က တစ်နေရာကနေ လာတဲ့အခါ ဖတ် အသုံးပြုသူ၊ ထို ၏ကွပ်မျက် pipeline ရပ်တန့်ထားသည် ပြောင်းလဲမှုများကို အတည်ပြုချက်မရမချင်း။ အတည်ပြုချက်အဆင်ပြေပါက၊ ပြုပြင်ထားသော pipeline ကွပ်မျက်ခံရသည်။
- PR က တစ်နေရာကနေ လာတဲ့အခါ ရေးသား အသုံးပြုသူ၊ ထို ခွင့်ပြုချက်မလိုအပ်ဘဲ ပြုပြင်ထားသော pipeline အမြဲတမ်း ကွပ်မျက်ခံရတယ်!!
အဆုံးသတ်အနေနဲ့ အများသုံး repositories တွေမှာရှိတဲ့ forks တွေကနေ လာတဲ့ PR တွေကို PPE ကနေ ပေါ့ပေါ့ပါးပါး ကာကွယ်ပေးထားပါတယ်။ ပြင်ပ (ဖတ်ရှု) အသုံးပြုသူတွေကိုတော့ အကာအကွယ်အချို့တော့ ရှိပေမယ့် အတွင်းပိုင်း (ရေးသား) အသုံးပြုသူတွေနဲ့ ဘာမှ မသက်ဆိုင်ပါဘူး။
အဘယ်သို့သောအကြောင်း ပုဂ္ဂလိက repos များမှ forks များမှ PR များ လာခြင်း?
PR များ forks မှစတင်၍ ကိုယ်ပိုင် အနားယူ
ဤအခြေအနေတွင် GitHub သည် အသုံးဝင်သော configuration setting အချို့ကို ပေးပါသည်။
အထက်ပါ setting များကို အောက်ပါနေရာများတွင် configure လုပ်နိုင်ပါသည် ကိုယ်တွင်းကလီစာတွေကို သို့မဟုတ်မှာ repo အဆင့်။
ဘယ်တော့လဲ မည်သည့်ရွေးချယ်မှုကိုမျှ အမှန်ခြစ်မထားပါ, GitHub မှာ လုပ်မှာက ခွင့်ပြုချက်တောင်းပါ နှင့် ပြုပြင်ထားသောအရာကို လုပ်ဆောင်မည်မဟုတ်ပါ pipelineဒါက အလုံခြုံဆုံး ဖွဲ့စည်းပုံပဲ!!
အဆိုပါ မလုံခြုံဆုံးဖွဲ့စည်းပုံ သည့်အခါဖြစ်ပါသည် "fork မှ workflow များကို လုပ်ဆောင်ပါ pull request"စစ်ဆေးပြီးဤကိစ္စတွင်၊ read နှင့် write user နှစ်မျိုးလုံးအတွက် အတူတူပင်၊ Github သည် ပြုပြင်ထားသော ကုဒ်များကို အလိုအလျောက် execute လုပ်ပါလိမ့်မည်။ pipeline!! ပြီးတော့ ဒီအခြေအနေကတောင် ဖြစ်နိုင်တယ် ပိုဆိုး အကယ်၍ "fork မှ workflow များသို့ write token များပို့ပါ pull requests"နှင့်"fork မှ workflow များသို့ secrets များနှင့် variables များပေးပို့ပါ pull requests"ကို အမှန်ခြစ်ထားပါတယ်။ ရှင်းရှင်းလင်းလင်း ခိုင်လုံတဲ့ အကြောင်းပြချက်မရှိရင် ဒါကို မလုပ်ပါနဲ့။
အကယ်၍“ခွဲခြမ်းစိတ်ဖြာခြင်းအတွက် ခွင့်ပြုချက် လိုအပ်သည် pull request Workflows” ကို အမှန်ခြစ်ထားလျှင်၊ အထက်ပါအခြေအနေသည် အတန်ငယ် ပိုမိုကောင်းမွန်လာသည်- GitHub သည် ခွင့်ပြုချက်တောင်းခံပြီး ပြုပြင်ထားသောအရာကို မလုပ်ဆောင်ပါ pipeline read user အတွက်ဖြစ်သော်လည်း write user အတွက်မူ execute လုပ်ဦးမည်ဖြစ်သည်။
ခက်ရင်းတွေ မြင်ဖူးတယ်၊ ဘယ်လိုလဲ ဘဏ်ခွဲများမှ လာသော PR များ?
PR များမှ အကိုင်းအခက်
ဒီအခြေအနေကို ကာကွယ်ဖို့အတွက် အားကိုးရမှာက ဘဏ်ခွဲကာကွယ်ရေးစည်းမျဉ်းများ.
repo level မှာ ဘယ် branch အတွက်မဆို branch protection rules တွေ ဖန်တီးနိုင်ပါတယ်။ ဒီ rules တွေက တစ်ချို့ကို ထပ်ထည့်ပေးပါတယ်။ ကာကွယ်ထားသော အကိုင်းအခက်များကို ပြုပြင်မွမ်းမံခြင်းအတွက် ကန့်သတ်ချက်များ.
စည်းမျဉ်းတစ်ခုကို "သို့" ပြင်ဆင်သတ်မှတ်သော်လည်းလိုအပ်ပါသည်။ pull request ပေါင်းစည်းခြင်းမပြုမီ"နှင့်"ခွင့်ပြုချက်များ လိုအပ်သည်" မွမ်းမံထားသည်။ pipeline PR ဖန်တီးပြီးသည်နှင့် အလိုအလျောက် လုပ်ဆောင်သွားပါမည်"ခွင့်ပြုချက်" သည် ပေါင်းစည်းမှုလုပ်ဆောင်ချက်အတွက်သာ အကျုံးဝင်ပါသည်။
သွယ်ဝိုက်အဆိပ်သင့်ခြင်းအကြောင်းကော။ Pipeline သတ်ခြင်း
အထက်တွင် ကျွန်ုပ်တို့မြင်တွေ့ခဲ့ရသည့်အတိုင်း D-PPE ကို အသုံးပြုခြင်းဖြင့် လျှော့ချနိုင်သည် pull_request_targetဒါပေမယ့် I-PPE နှင့် မသက်ဆိုင်ပါ.
pull_request_target ကိုအသုံးပြုပါက default checkout သည် base code ဖြစ်လိမ့်မည်။ သို့သော် ပံ့ပိုးပေးထားသော code (PR code) တွင် စစ်ဆေးမှုအချို့ကို validate လုပ်လိုပါက PR code ကို expressly checkout လုပ်ရန်လိုအပ်သည်။ ထို့ကြောင့် PR code သည် invoke လုပ်ထားသော shell script တစ်ခုခုကို ပြုပြင်ထားပါက pipeline, “အခြေခံ” (ဘေးကင်းသော) pipeline “ပြုပြင်ထားသော” shell script → Indirect PPE!! ကို ဆင့်ခေါ်ပါလိမ့်မည်။
ဒီအတွက် ဖြေရှင်းချက်က နည်းနည်းပိုရှုပ်ထွေးပါတယ် (pull_request_target လိုမျိုး မှော် bullet မရှိပါဘူး)။
ကျွန်တော်တို့၏ pipeline pull_request_target ကိုသုံးနေလို့ D-PPE အတွက် စိတ်ချရပါပြီ။ ဒါပေမယ့် I-PPE အတွက် အားနည်းချက်ရှိနေဆဲပါ။
ကျွန်ုပ်တို့ရဲ့ စမ်းသပ်မှု ဥပမာမှာ၊ build လုပ်ဖို့ အခြေခံအားဖြင့် PR code ကို checkout လုပ်ရပါမယ်၊ ဒါပေမယ့် build ကနေ ထုတ်လုပ်ထားတဲ့ artifact မှာ test တွေကို execute လုပ်ပါတယ်။
ဒီတော့ .. ဘာလို့ codebase နှစ်ခုလုံးကို မစစ်ဆေးတာလဲ။
- PR code ကို စစ်ဆေးပါ၊ အဘယ်ကြောင့်ဆိုသော် ကျွန်ုပ်တို့ တည်ဆောက်ပြီး စမ်းသပ်လိုသော code ဖြစ်သောကြောင့် ဖြစ်သည်။
- မူရင်းဗားရှင်းကို လုပ်ဆောင်ရန် Checkout Base code pipeline နှင့် build/tests script များ
ဒါကို လုပ်ဆောင်နိုင်ပါတယ် ထို codebase များကို မတူညီသော folder များသို့ စစ်ဆေးခြင်းbase code ကို root folder မှာ check out လုပ်ပြီး PR ကို တခြား folder တစ်ခုမှာ check out လုပ်နိုင်ပါတယ်။ ဒီကိစ္စမှာ root folder ကနေ build နဲ့ test script ကို folder အသစ်ထဲမှာ ထည့်ထားတဲ့ code နဲ့ execute လုပ်မှာပါ။
ဒါက လွယ်ကူတဲ့ ဖြေရှင်းချက်တစ်ခုပါပဲ!! ဒါပေမယ့် သင်ယူမှုအတွက် စိတ်ဝင်စားစရာကောင်းတဲ့ မူကွဲတစ်ခုကို မိတ်ဆက်ပေးချင်ပါတယ် (…)
GitHub workflow_run လှုံ့ဆော်မှုဖြစ်ရပ်
အပြင် pull_request_target, GitHub သည် နောက်ထပ် trigger event တစ်ခုကို ပေးသည်- workflow_runဤပွဲသည် ခွင့်ပြုသည် အကောင်အထည်ဖော်မှုတစ်ခု pipeline တခြားတစ်ယောက်အတွက် ပြဋ္ဌာန်းထားတဲ့ pipeline၏ အကောင်အထည်ဖော်မှု.
workflow_run နှင့် pull_request_target trigger များသည် တစ်ချက်တွင် ဆင်တူသည်- နှစ်ခုစလုံးကို privileged mode တွင် execute လုပ်မည်ဖြစ်ပြီး၊ PR ပြုပြင်ပြောင်းလဲမှုများရှိနေသော်လည်း၊ အခြေခံ pipeline ကွပ်မျက်ခံရလိမ့်မယ်!!
ကျွန်တော်တို့ရဲ့ လက်ရှိအခြေအနေကို ကြည့်ရအောင် pipeline:
name: PR TARGET CI
on:
pull_request_target:
branches: [ main ]
env:
MY_SECRET: ${{ secrets.MY_SECRET }}
jobs:
prt_build_test_and_merge:
runs-on: ubuntu-latest
steps:
# checkout PR code
- name: Checkout repository
uses: actions/checkout@v4
with:
# This is to get the PR code instead of the repo code
ref: ${{ github.event.pull_request.head.sha }}
# Simulation of a compilation
- name: Building ...
run: |
mkdir ./bin
touch ./bin/mybin.exe
ls -lR
# Simulation of running tests
- name: Running tests ...
id : run_tests
run: |
echo Running tests..
chmod +x runtests.sh
./runtests.sh
echo Tests executed.
#
# Let’s omit the check conditions at this moment …
#
- name: pr_check_conditions_to_merge
[...]
တည်ဆောက်မှုအပိုင်းသည် D-PPE အတွက် ဘေးကင်းသော်လည်း၊ စမ်းသပ်အပိုင်းသည် I-PPE အတွက် အားနည်းချက်ရှိနေဆဲဖြစ်သည်။
အဆိုပါ pipeline D-PPE အတွက် သူ့အလိုလို ဘေးကင်းပါတယ်၊ ဘာလို့လဲဆိုတော့ pull_request_target trigger။ ဒါပေမယ့် external shell script ကို invoking လုပ်တာကြောင့် test step က I-PPE ကို ထိခိုက်စေနိုင်ပါသေးတယ်။
I-PPE ကို ရှောင်ကြဉ်ခြင်း
အထက်ဖော်ပြပါ ရည်ရွယ်ချက် pipeline PPE အတွက် ဘေးကင်းစေရန်၊ ပံ့ပိုးပေးထားသော ကုဒ်ကို တည်ဆောက်ပြီး စမ်းသပ်ရန်ဖြစ်သည်။
ဒီတော့ .. ဘာလို့မခွဲတာလဲ pipeline နှစ်ခုထဲကို? တစ်ခုက တည်ဆောက်ဖို့နဲ့ နောက်တစ်ခုက စမ်းသပ်ဖို့..
- ပထမ pipeline (CI တည်ဆောက်ပါ) လိမ့်မည် PR ကုဒ်ကို စစ်ဆေးပါ (တည်ဆောက်ရန်), တည်ဆောက်မှုကို ပြုလုပ်ပြီး ရှေးဟောင်းပစ္စည်းတစ်ခုကို ထုတ်လုပ်ပါ။
- ဒုတိယ pipeline (စမ်းသပ် CI) လိမ့်မည် Base code ကို checkout လုပ်ပါ (shell script ပြုပြင်မွမ်းမံမှုကို ရှောင်ရှားရန်) ပြီးတော့ မူရင်း script တွေကို artifact နဲ့ ယှဉ်ပြီး execute လုပ်ပါ။
- စမ်းသပ် CI ကို ထပ်တူပြုရန် pipeline Build CI ပြီးနောက် လုပ်ဆောင်ရန် pipeline၊ ငါတို့သုံးမယ်။ workflow_run ခလုတ်။
ဒီလိုမျိုး:
- pipeline CI တည်ဆောက်ပါ is လုံခွုံသော နှစ်ခုလုံးကို D-PPE (ကြောင့်ရန် pull_request_target) နှင့် I-PPE (အဘယ်ကြောင့်ဆိုသော် ၎င်းသည် shell script ကို ဆက်လက်လုပ်ဆောင်ခြင်း မရှိတော့သောကြောင့်ဖြစ်သည်)။
- pipeline စမ်းသပ် CI လည်းဖြစ်ပါတယ် လုံခွုံသော နှစ်ခုလုံးကို D-PPE (ကြောင့်ရန် workflow_run) နှင့် I-PPE (ဘာလို့လဲဆိုတော့ မူရင်း shell script ကိုရဖို့ base code ကို checkout လုပ်လို့ပါ။)
နှစ်ခုလုံးရဲ့ code ကိုကြည့်ရအောင် pipelineဤပြုပြင်မွမ်းမံမှုများအရ s …
1st pipeline (CI တည်ဆောက်ပါ):
name: Build CI
on:
pull_request_target:
branches: [ main ]
env:
MY_SECRET: ${{ secrets.MY_SECRET }}
GITHUB_PAT: ${{ secrets.GH_PAT }}
jobs:
prt_build_and_upload:
runs-on: ubuntu-latest
steps:
- name: Checking out PR code
uses: actions/checkout@v4
if: ${{ github.event_name == 'pull_request_target' }}
with:
# This is to get the PR code instead of the repo code
ref: ${{ github.event.pull_request.head.sha }}
- name: Building ...
run: |
mkdir ./bin
touch ./bin/mybin.exe
# Save some PR info for later use by the 2nd pipeline
echo "${{github.event.pull_request.title}}" > ./bin/PR_TITLE.txt
echo "${{github.event.number}}" > ./bin/PR_ID.txt
# Upload the binary as a pipeline artifact
- name: Archive building artifacts
uses: actions/upload-artifact@v3
with:
name: archive-bin
path: |
bin
2nd pipeline (စမ်းသပ် CI):
ame: Test CI
on:
workflow_run:
workflows: [ 'PR TARGET CI' ]
types: [completed]
env:
MY_SECRET: ${{ secrets.MY_SECRET }}
GITHUB_PAT: ${{ secrets.GH_PAT }}
jobs:
deploy:
runs-on: ubuntu-latest
if: ${{ github.event.workflow_run.conclusion == 'success' }}
steps:
# By default, checks out base code (not PR code)
- name: Checkout repository
uses: actions/checkout@v4
# Download the artifact
- name: 'Download artifact'
uses: actions/github-script@v6
with:
script: |
let allArtifacts = await github.rest.actions.listWorkflowRunArtifacts({
owner: context.repo.owner,
repo: context.repo.repo,
run_id: context.payload.workflow_run.id,
});
let matchArtifact = allArtifacts.data.artifacts.filter((artifact) => {
return artifact.name == "archive-bin"
})[0];
let download = await github.rest.actions.downloadArtifact({
owner: context.repo.owner,
repo: context.repo.repo,
artifact_id: matchArtifact.id,
archive_format: 'zip',
});
let fs = require('fs');
fs.writeFileSync(`${process.env.GITHUB_WORKSPACE}/myartifact.zip`, Buffer.from(download.data));
# Unzip the artifact
- name: 'Unzip artifact'
run: |
unzip -o myartifact.zip
# Runs tests
- name: Running tests ...
id : run_tests
run: |
echo Running tests..
chmod +x runtests.sh
./runtests.sh
echo Tests executed.
#
# Let’s omit the check conditions at this moment …
#
- name: pr_check_conditions_to_merge
[...]
ဝိုး... ကောင်းတဲ့ ဖြေရှင်းချက်ပဲ!! ဒါပေမယ့် ….. ကျွန်တော်တို့ ဘေးကင်းရဲ့လား။ လုံခြုံမှု မရှိဘူးလို့ ကျွန်တော် ကြောက်တယ် 😭
တကယ်တော့၊ ကျွန်တော်တို့မှာ အားနည်းချက်အသစ်တစ်ခု ပေါ်လာပါပြီ။ ဘယ်ဟာလဲ။ ဒါက ကျွန်တော်တို့ရဲ့ နောက်ပို့စ်မှာ အကြောင်းအရာဖြစ်ပါလိမ့်မယ် 🙂 … စောင့်မျှော်ကြည့်ရှုပေးကြပါ။
PS: တောင်းပန်ပါတယ်၊ ကျွန်တော် တိတ်တိတ်နေလို့မရဘူး 🤐 .. ကြားဖူးလား ရှေးဟောင်းပစ္စည်း အဆိပ်သင့်ခြင်း ? 😂
