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@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@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@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@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.