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

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20241022/5a21a7f0/attachment.sig>