On Wed, 2021-11-10 at 14:42 +0100, Jan Kiszka wrote: > On 10.11.21 14:23, Bezdeka, Florian (T RDA IOT SES-DE) wrote: > > On Wed, 2021-10-13 at 14:22 +0200, Jan Kiszka wrote: > > > On 13.10.21 14:17, Florian Bezdeka wrote: > > > > For now the difference between the demo and the "ci image" is the > > > > removed sshd-regen-keys. That reduces the (first) boot time especially > > > > on low end CI hardware. Helps to stay within LAVA timeouts. > > > > > > > > CI builds will now use that file. > > > > > > > > > > Too many options. Can't we consolidate over a single CI/CT thing that > > > also includes the changes for ci-board? > > > > It has been a while, but coming back to this now... > > > > I agree, we have a lot of such option files, but after checking them > > all again: They all have a unique purpose. > > For users? I doubt that. We have > > - opt-ext4-gz.yml: It enables QEMU targets, and only those, to be > compatible with the LAVA test setup by compressing its ext4 images
It's the gitlab-ci config that limits it to qemu targets currently. But that could evolve with new targets being added. > > - opt-lava-test.yml: It switches wic-based targets, and that are only > the physical ones, to tarballs - again for LAVA purposes > This one was renamed in one of the previous patches to opt-ci-board.yml to make sure that this one is useful for real CI targets (only). It's up to the CI configuration to add it to the list of used options for new build/test tasks. > - opt-ci.yml: Removes packages, not relevant for the above images, and > only those That's the new one introduced here. Collecting only CI specific things. Nothing else. > > I really see no separate purposes, just separate files. That is likely > only for technical reasons. > > > > > We don't have a single CI/CT option file because the qemu test targets > > are different in comparison to the real board targets. We do not boot > > up a "disk"/wic image, we pass a kernel image to qemu. > > > > Without introducing opt-ci.yml I would have to spread the ci > > optimizations into several board specific configs, which would enable > > the ci optimization for "real board builds" as well. That is not what > > we want. > > > > Further ideas? > > > > What about introducing a ci image? Does that make sense? The content > > would nearly be the same as within opt-ci.yml now. > > An image alone would not consolidate those changes above into a single > one that can be controlled from a single opt-ci.yml file. > > We likely need a CI_BUILD bitbake variable that controls with bitbake > logic the changes needed for CI, with bitbake conditionals. Currently we can define new CI tasks/jobs by just adding them to the (gitlab) CI config, selecting the right option files for each task. As we have at least board specific adjustments: Wouldn't that mean that adding new targets would require recipe / bitbake adjustments? Purpose of this series was moving up to Debian 11. Maybe we could avoid this quite big refactoring here by just removing the CI optimizations again, and postpone that? > > Jan >
