Continuous Integration Build Failures

[Lei YU]

On Fri, Oct 25, 2019 at 4:21 AM Andrew Geissler <geissonator at gmail.com> wrote:
>
>
>
> > On Oct 24, 2019, at 10:40 AM, Brad Bishop <bradleyb at fuzziesquirrel.com> 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.
>
> Other then some old unsupported jenkins plugins, I’m not seeing any obvious way
> to this one.

It's a valid point, I have seen people submitting changes to gerrit
and got a build failure, but could not find the detailed log why it
fails.
Currently, there is only console logs on Jenkins, but the build/test
logs are not accessible.
Is there a way to post the build logs and test logs to a place, e.g.
Dropbox/GoogleDrive/etc, so that it could be persistent for a longer
time?