Continuous Integration Build Failures

Johnathan Mantey johnathanx.mantey at intel.com
Fri Oct 25 02:16:34 AEDT 2019


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 the maintainers of the CI system willing to make a change that aids
in debug?

Suggestions:

 1. Don't delete the log on build fails.
 2. Delete everything but the log ascii output on build fails.
 3. Email the ascii logfile for build fails
 4. Email a compressed debug bundle to the submitter?
 5. Allow build fails to be restarted by the submitter so the logs can
    be regenerated, inspected, and captured.
 6. other...?

-- 
Johnathan Mantey
Senior Software Engineer
*azad te**chnology partners*
Contributing to Technology Innovation since 1992
Phone: (503) 712-6764
Email: johnathanx.mantey at intel.com <mailto:johnathanx.mantey at intel.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20191024/d67a97ee/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20191024/d67a97ee/attachment.sig>


More information about the openbmc mailing list