Re: [PATCH] gitlab-ci: Use artifacts instead of dumping logs in the Cirrus-CI jobs

["Philippe Mathieu-Daudé" <philmd@linaro.org>]

On 15/2/23 16:45, Thomas Huth wrote:
> On 15/02/2023 15.57, Philippe Mathieu-Daudé wrote:
>> Hi Thomas,
>>
>> On 15/2/23 15:25, Thomas Huth wrote:
>>> The meson log files can get very big, especially if running the tests in
>>> verbose mode. So dumping those logs to the console was a bad idea, since
>>> gitlab truncates the output if it is getting too big. Let's publish the
>>> logs as artifacts instead. This has the disadvantage that you have to
>>> look up the logs on cirrus-ci.com now instead, but that's still better
>>> than not having the important part of the log at all since it got
>>> truncated.
>>>
>>> Fixes: 998f334722 ("gitlab: show testlog.txt contents ...")
>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>> ---
>>>   Note: I also tried to publish the junit xml files as artifacts
>>>   instead, but while the cirrus-ci docs claim to support it, I only
>>>   got unreadable XML output in my browser that way, so the .txt
>>>   files look like the better option to me.
>>>
>>>   .gitlab-ci.d/cirrus/build.yml | 7 +++++--
>>>   1 file changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/.gitlab-ci.d/cirrus/build.yml 
>>> b/.gitlab-ci.d/cirrus/build.yml
>>> index 7ef6af8d33..a9444902ec 100644
>>> --- a/.gitlab-ci.d/cirrus/build.yml
>>> +++ b/.gitlab-ci.d/cirrus/build.yml
>>> @@ -32,6 +32,9 @@ build_task:
>>>       - $MAKE -j$(sysctl -n hw.ncpu)
>>>       - for TARGET in $TEST_TARGETS ;
>>>         do
>>> -        $MAKE -j$(sysctl -n hw.ncpu) $TARGET V=1
>>> -        || { cat meson-logs/testlog.txt; exit 1; } ;
>>> +        $MAKE -j$(sysctl -n hw.ncpu) $TARGET V=1 ;
>>>         done
>>> +  always:
>>> +    build_result_artifacts:
>>> +      path: build/meson-logs/*log.txt
>>> +      type: text/plain
>>
>> How long is that log kept available?
> 
> No clue, I haven't seen anything related in the docs:
> 
>   https://cirrus-ci.org/guide/writing-tasks/#artifacts-instruction
> 
> ... but I assume they will at least be available for a couple of days so 
> you've got enough time to look at them in case a job failed.

OK thanks.