Closed murpdj72 closed 5 years ago
The build was successful x86 - Ran for 20 min 22 sec arm64 - Ran for 48 min 12 sec - We may have to bring in the defconfig_builder to prune this defconfig to our care abouts. It can be tailored to speed up the build. No reason to build a bunch of unnecessary code line rockchip or noveau arm - Ran for 34 min 28 sec
So we have some time to run other build checks or create some test matrix that run in another VM.
I still think we would do fine by building only the parts we work on. And if possible with travis, do a full build every weekend or so.
So just something like:
make defconfig
./scripts/config -m DRM_CDNS_MHDP -m SOMETHING_ELSE
make C=2 drivers/gpu/drm/bridge/mhdp8546.ko drivers/foo/bar.ko
This should give us feedback in some minutes instead of hours.
@tomba Doing the compile tests on the parts only test compilation not linking. Build can still break at linking stage if dependencies are not met in the Kconfig.
I wonder if we should do the partial compile tests on a for-next branch and do full build on the master. This way we can move the for-next branch quickly and then merge to master as needed.
Not sure how fast the development will be moving on this.
Yes, it's a compromise. We can also disable a lot of things in the kconfig, but that's kind of laborious to figure out what to disable.
Well the way travis works is it is basically it is the travis.yml file that controls the builds. So if we want to break it apart we may have to do 2 branches. 1 that does the compile tests and one that does the full compile tests. We could always create a cron job that merges in the master to the full compile test branch once a week or daily. the travis.yml would effectively say if (master) partial compile else do full compile. But I would have to figure that out to make sure travis does not try to run both tests and boot multiple unneeded VMs
Add the travis.yml to the kernel
Goals of the testing:
Signed-off-by: Dan Murphy dmurphy@ti.com