[PATCH] CI: Add a test for building without CMDLINE

Simon Glass sjg at chromium.org
Tue Oct 22 14:16:16 CEST 2024


Hi Tom,

On Mon, 21 Oct 2024 at 18:50, Tom Rini <trini at 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 <trini at 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 <sjg at 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


More information about the U-Boot mailing list