Continuous Integration Build Failures

[James Feist]

On 10/24/19 8:49 AM, Johnathan Mantey wrote:
> 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,

You can login to the Jenkins instance using your github credentials and 
re-trigger the build.


> 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>
>