On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote:
On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer michel@daenzer.net wrote:
On 2020-03-01 6:46 a.m., Marek Olšák wrote:
For Mesa, we could run CI only when Marge pushes, so that it's a strictly pre-merge CI.
Thanks for the suggestion! I implemented something like this for Mesa:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432
I wouldn't mind manually triggering pipelines, but unless there is some trick I'm not realizing, it is super cumbersome. Ie. you have to click first the container jobs.. then wait.. then the build jobs.. then wait some more.. and then finally the actual runners. That would be a real step back in terms of usefulness of CI.. one might call it a regression :-(
I think that's mostly a complaint about the conditionals we've written so far, tbh. As I commented on the bug, when I clicked the container job (which the rules happen to have evaluated to being "manual"), every job (recursively) downstream of it got enqueued, which isn't what you're describing. So I think if you can describe the UX you'd like we can write rules to make that reality.
But I don't really know which jobs are most expensive in terms of bandwidth, or storage, or CPUs, and even if I knew those I don't know how to map those to currency. So I'm not sure if the UI we'd like would minimize the cost the way we'd like.
- ajax