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

[Simon Glass]

Hi Tom,

On Tue, 22 Oct 2024 at 19:56, Tom Rini <trini at konsulko.com> wrote:
>
> On Tue, Oct 22, 2024 at 07:00:39PM +0200, Simon Glass wrote:
> > 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?
>
> I'd really rather not overwhelm our few build servers (of which you're
> providing most of).
>
> > 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?
>
> Yes, we could just do something like configs/qemu_arm64_lwip_defconfig
> but be sandbox_nocmdline_defconfig and it'll just be part of the normal
> world stage that already builds all of the sandbox targets.

Oh I see, yes I can do that.

Regards,
Simon