I don't think we will get really machine parseable error reports as many errors
are just spit out by random scripts. Also errors will almost always stop the
build. So there will only be the first real error being reported. But the
error reporting can be better.
--
Reply to this email
I fully support Petr's idea here. It would be amazing to use that data further
in the workflow and display that information nicely in koji, Copr, GitHub,
Gitlab... We could even think about automated retries for certain types of
errors (flakes, network problems) or even fix a spec file if a BR
At least it would be possible to say in which file to search for the error. Not
something the end user has to find himself. Example:
https://koji.fedoraproject.org/koji/taskinfo?taskID=105833248
But in general, I do not think the result should be pure boolean. More likely
something like enum,
I think rpmbuild should return different return code at least for different
sections, in which the failure occurred. But ideally also with lists of
relevant object types it knows.
--
Reply to this email directly or view it on GitHub:
On talk about AI by Tomáš Tomeček I have realized rpm building process it quite
terrible at providing machine processable results for failed builds. I think it
should be reported in machine parseable format, JSON for example.
When the build has failed on BuildRequires: installation, it should
