Continuous Integration Build Failures

[Johnathan Mantey]

Brad,
No I had not seen that doc.  That said, I worked with someone here to
run the CI build locally.  I got the Docker instance to perform a build
on the submission that instigated this email trail. The Docker instance
passed on my code changes.  Yet, the upstream Gerrit build does not. 
Now I don't have logfiles on the upstream Gerrit server to find out
why.  I believe I've done my due diligence for preparing the code for a
successful build.  At the end of the day the only place that matters for
build success/failure is the upstream system.  As such anything that can
be done to improve that system is, in my opinion, a benefit to the
community.

My specific issue is:
https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-networkd/+/24666
I have no idea why this is failing now that the logs have been deleted,
and I can't determine a way to manually start a new build to get logs
without pushing meaningless commits.  I'd rather not waste reviewers
time having to see email messages about meaningless commits.

On 10/24/19 8:40 AM, Brad Bishop wrote:
>
>> 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?

-- 
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/995576ab/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/995576ab/attachment.sig>