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

[Simon Glass]

Hi Tom,

On Tue, 22 Oct 2024 at 16:02, Tom Rini <trini at konsulko.com> wrote:
>
> On Tue, Oct 22, 2024 at 02:16:16PM +0200, Simon Glass wrote:
> > 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
>
> No, I don't want Azure and GitLab to diverge since Azure is where
> everywhere who isn't a custodian with git access can run CI and I keep
> encouraging more people to use it. And also note that the actual build
> took 8 seconds which is another reason it would be good to just drop it
> in to an existing job.

Oh I didn't know that about Azure. Could/should we have a public
gitlab pusher also? Or is that not possible?

Anyway, I cannot put it into a job which runs tests, since it doesn't
ever produce a command prompt. So that rules out the test.py stage,
since even if I use '-k nothing' it will still fail to see the prompt,
so the build will fail. I don't see any option but to put the build in
a separate piece?

Regards,
Simon