> On Jan 5, 2021, at 8:28 AM, Satish Balay <[email protected]> wrote:
>
> Well we have to look at artifacts for configure.log. Why is this more of a
> burden for slepc or externalpackage logs?
Some of the "artifacts" don't even exist to look at as artifacts; for
example slepc4py log files. And if we continue with the current model more and
more "artifacts" won't exist unless we add them (and we will forget to add
them). I am fine with the output being in configure.log (as is the case for
configures on external packages) or in make.log, it doesn't have to be in the
CI console window, but it can't be scattered in dozens of files.
>
> Whatever you say for slepc log applies for configure.log. If its only CI
> issue - and you want all logs on STDOUT - then you can modify
> .gitlab-ci.yml. Perhaps:
>
>
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 8f3d139235..f9cdd38abd 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -70,6 +70,7 @@ check-ci-settings:
> after_script:
> - date
> - ccache --show-stats
> + - more arch-*/lib/petsc/conf/*.log |cat
> artifacts:
> reports:
> junit: arch-*/tests/testresults.xml
>
> Satish
>
>
> On Mon, 4 Jan 2021, Barry Smith wrote:
>
>>
>> For packages that are built after PETSc configure (and or install is done)
>> slepc, hpddm etc we've traditional saved the output in its own file stashed
>> away somewhere.
>>
>> For the CI this is driving me nuts because when they fail the output is
>> essentially "lost" and thus it is impossible to determine what has gone
>> wrong.
>>
>> I have started to directly output in the same stream as the PETSc compiles
>> to make debugging much easier. Generally the packages are relatively small
>> and don't have a huge amount of output when compiling correctly. I did it
>> for PETSc4py and SLEPc (slepc4py is a mystery yet how it get's hidden in
>> slepc).
>>
>> Are there any large downsides to this plan?
>>
>> Barry
>>
>>
>
