Filtering / more control on artifacts:path
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Problem to solve
When the artifacts cannot easily be described with a glob pattern, we are sometimes forced to record much more than what's useful.
Further details
A yocto build produces an OS image, but builds lots of intermediate packages, and those build logs are precious. They can be found in the build tree as build/tmp/work/ARCH/PACKAGE/VERSION/temp/log.JOB.$PID, which leads to a specification of artifacts:path as "build/tmp/work////temp/log..*".
However, when generating an image making use of their "shared-state" caching feature to avoid rebuilding all individual packages, it is not useful to keep the numerous logs of jobs that merely pull from their cache (ie. that match the "log._setscene." pattern), they just waste space and make the useful logs hard to dig.
A workaround would be to enumerate the list of jobs to use a list of stricter glob patterns. But since each package recipe is free to add new jobs, this is tedious to enumerate and prone to error when the software changes, which kinda defeats the purpose of keeping logs.
Proposal
At least a couple of options come to mind:
- an artifacts:pathfilter that would allow to limit the scope of the artifacts:path glob pattern
- an artifacts:regexppath that would allow advanced expressivity (pcre-level), including negative lookahead/lookbehind assertions
- an artifacts:pathcommand that would allow specifying a command listing on its stdout the files to be considered artifacts (typically a "find" commandline on UNIX runners)
What does success look like, and how can we measure that?
N/A ?