BTW: for CI - the following might grab most of the config logs as artifacts
[assuming they are either config.log or configure.log] - but yeah - all logs
won't be in the same location [or single file, and good to have a fix that
works for both users and CI]
Satish
----
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 8f3d139235..53de0fd875 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -76,6 +76,7 @@ check-ci-settings:
name: "$CI_JOB_NAME"
when: always
paths:
+ - arch-*/externalpackages/*/*.log
- arch-*/lib/petsc/conf/*.log
- arch-*/lib/pkgconfig/PETSc.pc
- arch-*/tests/testresults.xml
On Tue, 5 Jan 2021, Satish Balay via petsc-dev wrote:
> 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
> > > >>
> > > >>
> > > >
> > >
> >
>
