Continuous Integration Build Failures

[Brad Bishop]

> On Oct 24, 2019, at 11:16 AM, Johnathan Mantey <johnathanx.mantey at intel.com> wrote:
> 
> I would like to propose a change to how the continuous integration system works.
> 
> I understand there are many builds, and there is a lot of data associated with the builds. Thus the current desire to remove the log file data in a short amount of time is a requirement. This works alright when the build succeeds. It's unhelpful when the build fails. Identifying where the build fails is impossible after approximately an hour. As an ordinary contributor I don't know how to make the CI system rebuild the source code so that the log files are available again without pushing some new change that consists of a useless piece of whitespace (or some other pointless change).  It shouldn't be necessary for the contributor to make requests for a build restart to the CI maintainers, they have their own agenda. 

Are you referring to the bitbake CI jobs or the repository CI jobs?

> 
> Are the maintainers of the CI system willing to make a change that aids in debug?
> 
> Suggestions:
> 	• Don't delete the log on build fails.
> 	• Delete everything but the log ascii output on build fails.
> 	• Email the ascii logfile for build fails
> 	• Email a compressed debug bundle to the submitter?
> 	• Allow build fails to be restarted by the submitter so the logs can be regenerated, inspected, and captured.
> 	• other...?

At first glance these are all good ideas.  Andrew how many of these can Jonathan implement himself and how many of them require access to the Jenkins instance?