20:13mareko: karolherbst: why do most CI tests depend on rustfmt?
20:13karolherbst: good question.. it should only trigger on *.rs file changes, but maybe the rules are incorrect there?
20:14mareko: if a .rs file is changed, most CI tests don't run before rustfmt is finished
20:15karolherbst: ahh... that's annoying. Maybe because of how stages work?
20:15mareko: no other code-validation test does that
20:15karolherbst: okay. I'll take a look tomorrow then and see if I can figure out why that is. Maybe something missing there
20:16mareko: e.g. why do vmware jobs depend on rustfmt
20:19karolherbst: I don't really know, but maybe it's better if one of the people more familiar with CI look into it, because I don't really see why that dep exists in the first place
20:20karolherbst: anyway, there shouldn't be a good reason why that dep is in place, so if somebody can figure out why it exists it's fine to remove it
21:09karolherbst: mareko: ".gitlab-ci/test/gitlab-ci-inc.yml" .required-for-hardware-jobs
21:10karolherbst: guess the motivation there was "if code validation fails, no point in running real hw tests"
21:13karolherbst: anyway.. not really caring myself, though we might be able to slim down the rustfmt container that much, that it basically never rebuilds and runs really really early? or we just remove that dependency
21:13mareko: there was no motivation, and if there was one, it was bullshit because now manual runs have to click on both build tests and rustfmt
21:14karolherbst: well, discuss this with the people having added that dependency
21:14mareko: you can't come up with a dumber idea than make piglit testing depend on code formatting
21:17mareko: especially when one is GL and another one is rust
21:22karolherbst: I don't really have an opinion on this, and I'm sure the CI folks had reasons to add this dep, but I'm sure we can also change it if it's causing more issues than anticipated. Anyway, might be better to discuss it on an MR or tomorrow or something.