[RFC 0/2] Do not stop with an error when mkimage fails

[Rasmus Villemoes]

On 09/11/2021 20.42, Tom Rini wrote:
> On Tue, Nov 09, 2021 at 08:21:07PM +0100, Heiko Thiery wrote:
>> Hi Wolfgang,
>>

>> I know this is not a perfect solution but I don't know how to get my
>> board merged without doing this kind of workaround for the U-Boot CI.
> 
> Unfortunately in these days of needing multiple inputs to create a
> functional image and also needing to have CI be able to be at all
> useful, what we do in many many many cases is yell loudly to the user
> that the resulting file here will NOT work and why.  So yes, some "yell
> it won't work but not return non-zero exit status" is the norm.
> 
> I would be very much open however to some way to handle this
> differently.  Some environment variable our tools check for and then
> yell-but-succeed?  Some other idea?  I'm just thinking out loud here.

Yes, I believe the build system must be taught some env var (or other
means) for opting in to this behavior. I've mentioned this example
before: Imagine some CI system tracking master branches of various Yocto
meta-layers. One of those recipes is responsible for providing one of
those infamous binary blobs, but one day the recipe is updated to
provide another version, so now the filename is different (this has
happened for some imx8m recently). No amount of yelling is going to
prevent the CI from thinking "great, the U-Boot build succeeded, now
let's deploy that artifact to the test rack and run our test suite".
Insta-brick. Apart from forcing one to drive to the office to unbrick
the victim boards, figuring out what went wrong is also going to be
quite unpleasant, since doing a manual build seems to work just fine.

And even in the interactive, developer-working-in-a-terminal, case,
there's no guarantee that the yelling hasn't scrolled away because of
other make output after the should-have-failed target has been "built".

Rasmus