[petsc-dev] builds of PETSc based packages should not get their own secret files

[Satish Balay]

On Tue, 5 Jan 2021, Satish Balay via petsc-dev wrote:

> On Tue, 5 Jan 2021, Barry Smith wrote:
> 
> > 
> > 
> > > On Jan 5, 2021, at 8:28 AM, Satish Balay <balay at mcs.anl.gov> 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).

BTW: If the logs are in a single location - and we have a wildscard (*.log or loc/*) that can capture them all - there won't be an issue with 'forget to add'. But a single log is also fine [if the contents are well separated for each package - like 'more *.log' does..]


>   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. 
> 
> We've never saved config.log [or equivalent] for all externalpackages [build either during configure or after petsc]
> 
> Currently we just save the build logs [to either configure.log - for packages that are built during configure, or to PETSC_ARCH/lib/petsc/conf - for packages that are built after petsc.
> 
> If we can add config.log [or equivalent] for  all externalpackages to some log file - or to PETSC_ARCH/lib/petsc/conf - that would be fine [and can be added to artifacts].
> 
> [currently make.log equivalent that we dump into configure.log is a bad format - stdout and stderr separated - so hard to co-relate errors to the commands invoked]
> 
> 
> BTW: One of the reasons we had separate petsc4py.log and slepc.py  log was  we wanted make.log clean for our users - so that the commands we recommend [for subsequent steps] are not easily ignored.
> 
> [anything on stdout for CI will also be on stdout for users]

However we can have it saved in a log - and than do a 'cat' [as shown below] - to have the logs on stdout - for CI (and avoid for users)

But then - we do want an easy mechanism for users to send us logs [here a single logfile or a tarball that users can send u is most convenient] 

Satish

> 
> Satish
> 
> 
> > 
> > 
> > > 
> > > 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
> > >> 
> > >> 
> > > 
> > 
>