Bug 8760

Summary:	Autobuilder additional task log availability
Product:	[Infrastructure] AutoBuilder	Reporter:	Benjamin Esquivel <benjamin.esquivel>
Component:	autobuilder	Assignee:	Unassigned <unassigned>
Status:	RESOLVED OBSOLETE	QA Contact:
Severity:	enhancement
Priority:	Medium	CC:	anibal.limon, elizabeth.flanagan, infras.ab.watcher, Infras.watcher, JPEWhacker, randy.macleod, tvgamblin
Version:	unspecified
Target Milestone:	Future
Hardware:	x86
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	No (bug/feature does not impact docs)

Description Benjamin Esquivel 2015-12-03 22:59:42 UTC

Provide means of obtaining/browsing the logs that the filesystem holds upon completion of a target build. 

One way of achieving this is to expose the sub-tree where the build happened and let the user navigate through, set a policy to erase old data (a week perhaps) to avoid.

Another way could be to whitelist which logs you want to save and compress them and move to a specified location.

Either way requires to place a link in the build details page to this data and it also requires the ability to not overwrite the current set of logs in the filesystem of each build like it is now.

Comment 1 Beth Flanagan 2015-12-08 18:21:42 UTC

So, some potential issues with this.

1. build-workers are not normally accessible outside of the build cluster. This is for security reasons to ensure that only the build controller is accessible.
2. While we can do this, there is no way of ensuring that the data will be there. Build directories are reused the moment that particular build is farmed out to that particular server.

A better solution here might be to publish the logs. However, that is a substantial amount of data which causes it's own set of issues.

Comment 2 Benjamin Esquivel 2015-12-08 18:26:33 UTC

thanks for replying, I see your point.

On publishing the logs, we would need to whitelist what we want to publish (dir level won't be that bad) and then we could tar them, they are mostly text so compression would be very nice there

Comment 3 Joshua Watt 2022-03-24 15:20:40 UTC

It might be possible to report the log files into the bitbake event stream, which already has mechanisms to be recorded and views (e.g. via toaster).

Comment 4 Randy MacLeod 2026-07-23 15:20:56 UTC

We've done other thing and so there are alternatives.
Open a new bug if you disagree.