[Development] Solutions for ensuring that changes in upstream modules are tested with downstream modules before merging
Shawn.Rutledge at qt.io
Tue Jun 15 22:57:16 CEST 2021
On 2021 Jun 7, at 15:30, Mitch Curtis <mitch.curtis at qt.io<mailto:mitch.curtis at qt.io>> wrote:
Some I can think of:
- Slower git operations.
- Slower build times for qtdeclarative devs. You can use e.g. ninja targets, but you would have to do this every time you build. Ideally we’d add a configure option for this, like -no-gui in qtbase, so that they don’t need to build qtquickcontrols2.
FWIW, I’m routinely building all of Qt together (the modules that I have anyway) with cmake and ninja. (It’s around 15k steps, building all autotests but not examples. A Zen3 processor and ccache make it bearable. Before that, I was using icecc.) So the cases where I have broken something in controls by making a change in qtdeclarative are usually only test failures (behavior changes), not build failures, right? (Or at least not build failures that I didn’t know about.) I never run all autotests in all modules locally, because it takes too long. Even running all tests in qtdeclarative takes too long, except when the change is so invasive that I know I really need to. If I’m worried about a specific change breaking controls, I run those tests. (The script to run tests in xephyr is handy, so I can keep using the computer while they are running.)
- Creator would probably be quite a bit slower to work with having both of these in one project.
Qtdeclarative is already a rather big module. And Creator is slow, for sure. It’s been a couple of years since I could use it at all on my older laptops without enough memory.
This why I like the idea of just running qtquickcontrols2 tests for each qtdeclarative change: it doesn’t waste developer time (and again, CI integrations don’t count since they shouldn’t be wasting developer time).
Hopefully that will work, yeah.
Though then you do lose the ability to use controls in examples, which does seem like a huge loss.
It depends whether we care about being able to automatically test examples without building controls first, right? Otherwise I thought the existing advice lately is to go ahead and use controls in examples?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development