5 ms·
> - Our devops team has had to make it so we can re-trigger our CI (or add additional pipelines) via comment-commands, while in BitBucket we were able to add cu
by mhitza 5y ago
> - Our devops team has had to make it so we can re-trigger our CI (or add additional pipelines) via comment-commands, while in BitBucket we were able to add custom buttons to the PR menu. This means there's a lot of noise of comments that just say "/retrigger-ci" or some such.
Job re-runs are more than one click away unfortunately. But I'd be curious, outside a failing job due to flakiness or GitHub instability; for what other reason do you use this functionality?
- ollien 5y agoThe big one that I can think of is triggering our "packaging" pipelines. We have some packages published separately from our main releases (which are not published via CI), so we have to trigger separate pipelines for them. We could _probably_ have some kind of filter based on directories, and honestly I'm not sure why we don't (probably so it's deliberate). Anyway, hope that answers your question :)
- mhitza 5y agoMaybe the gh command line can be useful for your use-case. Although you might want to keep the comment trigger style for historical/audit reasons, or if non-devs are allowed to trigger those downstream jobs as well.