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