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.
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.
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
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).
We've done other thing and so there are alternatives. Open a new bug if you disagree.