kata-containers Kubernetes CI could take advantage of the "latest" kata-deploy image (please, see: https://github.com/kata-containers/kata-containers/issues/1710), consuming it and smartly only updating the needed bits according to the PR being raised.
For instance, considerind we habe a kata-deploy image with the latest merged commit, whenever CI is triggered, we could simply check:
Did the kernel code change between the latest kata-deploy image and the current PR?
If not, do not build the kernel;
Did the qemu code change between the latest kata-deploy image and the current PR?
If not, do not build QEMU;
Did the agent code change between the latest kata-deploy image and the current PR?
If not, do not build the rootfs image;
And those could save a huge amount of CI time (and money).
kata-containers Kubernetes CI could take advantage of the "latest"
kata-deploy
image (please, see: https://github.com/kata-containers/kata-containers/issues/1710), consuming it and smartly only updating the needed bits according to the PR being raised.For instance, considerind we habe a
kata-deploy
image with the latest merged commit, whenever CI is triggered, we could simply check:And those could save a huge amount of CI time (and money).