我想把一些中間管道,等待一個web鉤被擊中。理想情況下,我的管道會做這樣的事情:等待,直到webhook被觸發
- 部署到QA
- 合併請求
- 部署到UAT
- 部署至正式發佈
我已在 「合併請求」 階段創建合併請求(在GitLab中)。那部分完成了。我現在要等到合併請求被接受後才能進入下一階段。我很喜歡它是一個webhook。
我可以寫一些代碼來輪詢請求,但如果可以的話,我想避免輪詢。
我想把一些中間管道,等待一個web鉤被擊中。理想情況下,我的管道會做這樣的事情:等待,直到webhook被觸發
我已在 「合併請求」 階段創建合併請求(在GitLab中)。那部分完成了。我現在要等到合併請求被接受後才能進入下一階段。我很喜歡它是一個webhook。
我可以寫一些代碼來輪詢請求,但如果可以的話,我想避免輪詢。
我通過GitLab API創建我的合併請求來解決這個問題。然後輪詢該API並等待狀態被「合併」。我寧願有一個webhook來避免投票。但waitUntil
函數在輪詢之間慢慢增加了更多時間,因此它不會過多地對系統徵稅。
我不確定是否有插件允許您在等待webhook時阻止作業執行。
我覺得更直接的方法是一分爲二的管道:
第二個管道可以被配置爲使用GitLab plugin for Jenkins觸發。據我所知,你可以在README.md
中關注the example,但只有在對目標分支進行推送時纔會觸發你的觸發器,例如,如果所有的合併,要求的目標master
:
triggers {
gitlab(triggerOnPush: true, triggerOnMergeRequest: false, branchFilterType: 'master')
}
這樣做的好處是,在等待網絡掛接(這可能需要一段時間取決於在變化的大小你不捆綁奴隸合併請求和誰在審查他們)。
這個問題引發的唯一問題是如果你必須保持兩個劇本的狀態。我之前編寫過管道,在相關資源的名稱中使用了獨特的sha。在你的場景中,你將失去對第二個管道中該變量的訪問。
這是我考慮過的一個選項,我很感謝您的回覆,但這是一個極端的解決方法,這是最後的解決方法。 我寧願調查MR,然後把管道分成兩部分。 – Eddie
如果你得到這個工作,我很想聽到更多關於它!我會密切關注這個話題,祝你好運! – nicr9
完成了,我沒有做你的建議,閱讀其他答案。我做的有點不同,信息和我會解釋。 – Eddie