Open hd9 opened 2 months ago
Hi, thanks for the kind words.
When rockcraft pack fails, It could surface the upmost functional error/exception by default.
I agree 110% with the spirit of the request, this would indeed be most useful. The problem here is this: that override-build
code is executed with bash, and Rockcraft itself has no idea about its contents or the semantics of what's being built. That example is I assume Go code, where it's idiomatic to prefix error statements with error:
, but that's just one of the "things that can go wrong". As you might know we currently support python, node, java, autotools, cmake, ... in addition to "anything goes" override-build
scripts.
We've been thinking about this recently and are definitely interested in suggestions on how to handle this in the general case.
What needs to get done
The logs provided by the
rockcraft
CLI are really detailed and very useful. However, I believe the default behaviour could be enhanced by surfacing additional information.I'd like to propose a minor enhancement to
rockcraft pack
that could save developers a lot of time. The idea is to expose the functional error/exception to the developer by default on pack errors.Example
When building my rock,
rockcraft
provided this generic message, which includes no context as it relates to my solution:However, this one line buried in the log contains the most relevant information:
error: invalid slice reference "libgomp1" in slices/httping.yaml
With that info, it takes the developer a couple of seconds to fix the issue. Without it, it could take them a couple of minutes just to find it.
Why it needs to get done
When
rockcraft pack
fails, It could surface the upmost functional error/exception by default.With this proposal,
rockcraft pack
would be augmented (see line 5 below) to show the error by default, eliminating the need to check logs in most situations.Thanks and great work Team!