On Fri, Feb 28, 2020 at 11:00 AM Rob Clark robdclark@gmail.com wrote:
On Fri, Feb 28, 2020 at 3:43 AM Michel Dänzer michel@daenzer.net wrote:
On 2020-02-28 10:28 a.m., Erik Faye-Lund wrote:
We could also do stuff like reducing the amount of tests we run on each commit, and punt some testing to a per-weekend test-run or someting like that. We don't *need* to know about every problem up front, just the stuff that's about to be released, really. The other stuff is just nice to have. If it's too expensive, I would say drop it.
I don't agree that pre-merge testing is just nice to have. A problem which is only caught after it lands in mainline has a much bigger impact than one which is already caught earlier.
one thought.. since with mesa+margebot we effectively get at least two(ish) CI runs per MR, ie. one when it is initially pushed, and one when margebot rebases and tries to merge, could we leverage this to have trimmed down pre-margebot CI which tries to just target affected drivers, with margebot doing a full CI run (when it is potentially batching together multiple MRs)?
Seems like a way to reduce our CI runs with a good safety net to prevent things from slipping through the cracks.
Here are a couple more hopefully constructive but possibly bogus ideas:
1. Suggest people put their CI farms behind a squid transparent caching proxy. There seem to be many HowTo's on the internet for doing this and it shouldn't be terribly hard. Maybe GitLab uses too much HTTPS and that messes things up? If not, this would cut downloads to one-per-farm rather than one-per-machine
2. Add -Dstrip=true to the meson config. We want asserts but do we really need those debug symbols? Quick testing on my machine, it seems to reduce the size of build artifacts by about 60%
Feel free to tell the peanut gallery (me) why I'm wrong. :-)
--Jason