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 <[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).
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 > > >> > > >> > > > > > >
