Hi Tom, On Tue, 22 Oct 2024 at 16:02, Tom Rini <tr...@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 <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 > > 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
