GitLab CI/CD課程7

Trigger Pipeline on Merge Request

除了如前篇所述,我們原只需要在main branch進行完整pipeline作業外

在GitLab上還有一個branch可能也需要進行一遍pipeline作業內容

也就是 →merge request branch

然後可能只進行pipeline中的test的作業

"Merge Request"亦或是Github上稱為的"Pull Request"

也就是一個請求合併到另一個Branch的動作

為何不直接merge進到main branch,還要多搞一個臨時的merge branch?

• 因為在main branch這個過度階段就提供了一個re-view code的機會!
• 透過以下方式,立體化了code的變更:
• 1.請求的描述
• 2.commit的清單
• 3.Code的變更內容與內部Code的re-view
• 4.Comment的區塊甚至還有其他內容
• 是在實際真的merge到main之前更好的協作模式(Best Practice)

merge branch跑test作業,對於main 或feature branch本身來說:

• main繼續維持stable狀態
• feature branch不用每次commit都搞test作業

當branch真的merge進到main(Merge Request approved)

main這時才需要執行完整的pipeline作業

實作:

首先設立條件,不要讓merge request事件觸發pipeline

非main且非merge request事件的,就不執行,否則一律要執行之意

但是main branch本身的merge還是要能執行打包與佈署,所以在加回:

完整版如下:

commit後就觸發pipeline執行:

這時候回頭刪除前面做的feature branch,並且重建

建立新的branch:

然後針對這個新的branch改改裡面的readme.md

隨便加點內容後commit:

此時可以去觀察看看pipeline是否有被觸發執行:

回到branch清單

執行該feature/payment-service的branch的merge request

就像菜鳥發動PR請求那樣的意思,接著要請資深的來審核確認

這時會跳轉到以下畫面:

資深人員看後面內容ok就可以按下Approve紐

資深人員可以切換到其他頁面去看變更內容:

此時pipeline就應該被觸發至少test的作業:

此時變更還沒有被Approve,也就是沒有真的merge到main裡面!

參考課程(reference)