Hi Tom, On Mon, 21 Oct 2024 at 18:50, Tom Rini <tr...@konsulko.com> wrote: > > On Mon, Oct 21, 2024 at 06:32:18PM +0200, Simon Glass wrote: > > Hi Tom, > > > > On Mon, Oct 21, 2024, 16:33 Tom Rini <tr...@konsulko.com> wrote: > > > > > > On Mon, Oct 21, 2024 at 03:44:49PM +0200, Simon Glass wrote: > > > > > > > Something this breaks, so add a test to keep it working. Since sandbox > > > > enables a lot of options, it is a good board to use. > > > > > > > > Signed-off-by: Simon Glass <s...@chromium.org> > > > > --- > > > > > > > > .azure-pipelines.yml | 8 ++++++++ > > > > .gitlab-ci.yml | 11 +++++++++++ > > > > 2 files changed, 19 insertions(+) > > > > > > I don't like this because "sandbox" is one of the longest run-time > > > build options due to all of the tests it runs. And given how we break > > > down the jobs this will make a further bottleneck. Can we just disable > > > CMDLINE in one of the existing sandbox defconfigs instead please? > > > Perhaps sandbox_spl since that only does SPL related pytests? > > > > Actually we do boot into U-Boot proper as some tests need to check > > that SPL did the right thing. > > > > Note that this patch doesn't run any tests at all. It just tries to > > build sandbox without CMDLINE > > Is there no existing thing we can put this in? And have we had another > problem with CMDLINE=n ? It's not cheap (wall clock) to add another > stage, especially in Azure, I'd really rather figure some way to bundle > this in with what we already do. Heck, following on with > qemu_arm64_lwip_defconfig I'd rather just add > sandbox_no_cmdline_defconfig and use #include so that it's just a few > lines of defconfig anyhow, but merged in with existing builds.
No, I have not seen any problems with CMDLINE as it is, but there are some BOOTSTD cases which I would like to check, since disabling the command-line and using programmatic boot is something I'd like to eventually test. So this is just a starting point. In the end perhaps we have a new sandbox variant, or can take over the SPL one...but I'm not sure yet. If Azure is a problem, we could perhaps just do it in gitlab, where we have more runners. A build variant isn't the sort of problem that would be different between gitlab and Azure. The run is at [1] and it only took 1m19s - I suppose you saw that it is in the 'world build' section and no tests are run. Regards, Simon [1] https://source.denx.de/u-boot/custodians/u-boot-dm/-/jobs/924269
