On Fri, 2021-09-17 at 15:38 +0200, Alexander Kanavin wrote:
> There are additional logs there (such as task log or qemu
> console output), which can be useful for debugging test failures.
>
> [YOCTO #14518]
>
> Signed-off-by: Alexander Kanavin <alex@...>
> ---
>  scripts/collect-results | 8 +++-----
>  1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/scripts/collect-results b/scripts/collect-results
> index 93834d6..3663330 100755
> --- a/scripts/collect-results
> +++ b/scripts/collect-results
> @@ -3,11 +3,9 @@ WORKDIR=$1
>  DEST=$2
>  target=$3
> 
> -RESFILE=$WORKDIR/tmp/log/oeqa/testresults.json
> -
> -if [ -e $RESFILE ]; then
> -    mkdir -p $DEST/$target
> -    cp $WORKDIR/tmp/log/oeqa/testresults.json  $DEST/$target/
> +mkdir -p $DEST
> +if [ -e $WORKDIR/tmp/log/oeqa/ ]; then
> +    cp -rf $WORKDIR/tmp/log/oeqa/ $DEST/$target
>  fi
> 
>  if [ -e $WORKDIR/buildhistory ]; then

I'm not sure about this since it has the potential to add a lot of files to the
release directories and I suspect that will confuse the releases and people
looking at them. At the very least we need to think about layout here...

When I proposed we improve the logging on the autobuilder, I was thinking more
about printing the logfiles on the console in the failure case. That way the
logs are immediately visible on the autobuilder log output people are looking at
and you don't have to go digging for the files. I can see pros/cons to both
approaches though.

Cheers,

Richard