One of the layers in my docker template is to build a bunch of python packages based upon a requirements file. One of the builds fails and the detail about the step does not wrap but rather clips. How do I see the full details of the line that fails?
[Build] main [=========> ] 46% Step 6/13: ERROR: Command errored out with exit status 1: /usr/bin/python3.6 -u -c 'impo…
Hi,
Can you please let us know how did you build your application, using Balena CLI or via git push?
Hi, I was using the balena cli using balena build -a <app name>. I was working on reducing the image size so trying different things without pushing to devices.
Hi @0xff,
Could you try the same command by prepending DEBUG=1 in your command, like this:
DEBUG=1 balena build -a <app name>
? This should emit more details about the error.
What architecture are you targeting? In case that’s different from the architecture of your computer, then you probably also have to add the --emulated argument in the balena build command.
Also can you clarify the balena-cli version that you are using and on what OS?
Kind regards,
Thodoris
Yes, thanks. I managed to fix the issue that was causing fails but the thrust of this concern is that information is lost because the build line clips and does not wrap.
BTW when I do builds on my system using the --emulated flag, I get the message:
[Info] Building for rpi/raspberry-pi
[Info] Docker Desktop detected (daemon architecture: "x86_64")
[Info] Docker itself will determine and enable architecture emulation if required,
[Info] without balena-cli intervention and regardless of the --emulated option.
I’m pretty much of a noob in this world so not quite sure what the mechanics are under the hood.
I realize that you are on a recent balena-cli, since this wasn’t supported in previous versions.
I see your point on the error message clipping and will open an issue to track this.
Thanks for reporting this.
Can you also let us know which balena-cli version and what OS you are using?
Kind regards,
Thodoris
Adding to my colleague’s last message and questions, I was unable to reproduce the message clipping issue with the following trivial Dockerfile:
FROM arm32v7/busybox
RUN /bin/false a very long line that errors so long in fact that it should cause the error message to be clipped that is if only I am able to reproduce the issue as kindly reported earlier today
CMD /bin/sh
In the example above, the output of balena build produces the full error message:
$ balena version -a
balena-cli version "11.21.5"
Node.js version "10.17.0"
$ balena build -a test-rpi ~/balena/other/simple_container/
[Info] Creating default composition with source: /Users/paulo/balena/other/simple_container
[Info] Building for armv7hf/raspberrypi3
[Info] Docker Desktop detected (daemon architecture: "x86_64")
[Info] Docker itself will determine and enable architecture emulation if required,
[Info] without balena-cli intervention and regardless of the --emulated option.
[Build] Built 1 service in 0:01
[Build] main [======> ] 33% Step 1/3: ---> 723ce4685637
[Error] Build failed
The command '/bin/sh -c /bin/false a very long line that errors so long in fact that it should cause the error message to be clipped that is if only I am able to reproduce the issue as kindly reported ealier today' returned a non-zero code: 1
Therefore, to help us reproduce the error and determine why it happens, could you also share your Dockerfile? Or at least the step / line that causes the error.
Regarding the info message “Docker itself will determine and enable architecture emulation if required,” it refers to the fact that Docker Desktop itself (on macOS or Windows) provides architecture emulation (https://docs.docker.com/docker-for-mac/multi-arch/), so the balena CLI does not need to install QEMU on the image being built, as described in the blog post Building ARM containers on any x86 machine.
I updated to 11.21.5.
Here’s the setup that will show the problem.
FROM balenalib/%%BALENA_MACHINE_NAME%%-alpine-python:3.6-build as build
WORKDIR /usr/src/app
COPY /lib/requirements3.txt /lib/requirements3.txt
RUN pip3 install -r /lib/requirements3.txt
Then put in requirements3.txt a bogus package name (notavalidpackage in my case). Make the terminal window small and run the build:
[Build] solmon [====> ] 22% Step 4/18: ERROR: No matching distribution found for nota…
[Build] metrics Successfully tagged balena_metrics:latest
[Error] Build failed
The command '/bin/sh -c pip3 install -r /lib/requirements3.txt' returned a non-zero code: 1
Error: The command '/bin/sh -c pip3 install -r /lib/requirements3.txt' returned a non-zero code: 1
at Stream.<anonymous> (/usr/local/lib/node_modules/balena-cli/node_modules/resin-docker-build/build/builder.js:178:23)
at Stream.stream.write (/usr/local/lib/node_modules/balena-cli/node_modules/through/index.js:26:11)
Note that this is just a demonstration - in my case there was a long python string that was being run such that I couldn’t easily see where the issue was.
To get around this I have made the terminal window really wider (wider than the screen) to capture the line but it’s a lot of contortions for what could be a simple fix of simply wrapping the line. My guess is that this was not done because it would aesthetically less pleasing, in which case perhaps only wrap in case of failure?
Thanks for the update and I can reproduce this per your steps.
[Build] Built 1 service in 0:11
[Build] main [====================>] 100% Step 4/4: ERROR: No matchi…
[Error] Build failed
There is an issue here https://github.com/balena-io/balena-cli/issues/1573 to track this.
@0xff, thank you for sharing the test case / Dockerfile that reproduces the error. I’ve found that the --logs option to balena build allows the full error messages to be displayed:
Without the --logs option:
$ balena build ~/test --arch i386 --deviceType intel-nuc
...
[Build] main [================> ] 80% Step 4/5: ERROR: No matching distribution found for notavalidpackage (from -r /sr…
With the --logs option:
$ balena build ~/test --arch i386 --deviceType intel-nuc --logs
...
[Build] main Step 4/5 : RUN pip3 install -r /src/requirements3.txt
[Build] main ---> Running in 74be836cb062
[Build] main ERROR: Could not find a version that satisfies the requirement notavalidpackage (from -r /src/requirements3.txt (line 1)) (from versions: none)
[Build] main ERROR: No matching distribution found for notavalidpackage (from -r /src/requirements3.txt (line 1))
This is not obvious, though. Changing the default behaviour to be as if --logs had been specified might have backwards compatibility issues or unintended consequences (if I am not mistaken, the same --logs flag/behaviour applies to the balena deploy and balena push commands, and the latter affects limited overall buffer sizes for logs generated by the balenaCloud builders and stored in the balenaCloud API database), but something simpler yet harmless that I am thinking is for the CLI error message in these circumstances to recommend re-running the build command with --logs flag, so at least the flag becomes less obscure. I am going to add this thought to that Github issue…
Awesome! Thanks for noting the --logs option!