Re: [petsc-dev] error in Jenkins but not nightly

[Smith, Barry F. via petsc-dev]

> On Jun 10, 2019, at 4:31 PM, Balay, Satish <ba...@mcs.anl.gov> wrote:
> 
> Well its a complex automation problem..
> 
> For one - all dependencies would have to be rebuilt - and then manage
> the new/old locations of the packages.  i.e its running 2 or more
> builds in 1. [with a different prefix in each build]

  Of course each examples/arch- has its own prefix and yes to make it simpler 
if any prebuilt needs updating just wipe the current prefix directory and 
rebuild all. The rebuilds would be super infrequent so the total rebuild is a 
trivial cost.
  
   I would stash the prefix prebuilt(s) inside the PETSc directory so they are 
trivial to locate (don't need additional directory information) but I suspect 
you don't like that. Note I would stash the spack version also inside the PETSc 
directory for the same reason. 

   Note that we can support doing the prebuilts both with the spack approach 
and without to satisfy the spack haters and may the approach with the least 
failures win.

  Barry

> 
> Satish
> 
> On Mon, 10 Jun 2019, Smith, Barry F. via petsc-dev wrote:
> 
>> 
>>  Yes. If the testing system were smart enough we could have the tests 
>> actually update the "prebuilt" automatically when things change. This would 
>> be more scalable in human efficiency. In addition when setting up a new test 
>> machine no need to manually make the prebuilts, the testing will just build 
>> them the first time it is run.
>> 
>>   Each examples/arch-* would have a variable listing the packages it uses 
>> that it wishes to be prebuilt. Each examples/arch-* would have list a dir 
>> for keeping its prebuilts. This could possibly be in the petsc directory. 
>> The script would check for any missing prebuilt, then build them with 
>> --prefix. It would then check using the version in the package.py and the 
>> version of the prebuilt (how to get that info easily?) and rebuild any 
>> packages that need updating with --prefix. Easy Peasy. Then run the regular 
>> tests.
>> 
>>  Barry
>> 
>> 
>> 
>> 
>>> On Jun 10, 2019, at 11:36 AM, Balay, Satish <ba...@mcs.anl.gov> wrote:
>>> 
>>> Ok - this must be the result of having prebuilt external packages used
>>> for jenkins - for both maint/master [while master changes with updates
>>> to use newer versions]
>>> 
>>> I think I might have to split maint/master part of prebuild external
>>> packages - and upgrade the master version [as master gets updated with
>>> newer versions].
>>> 
>>> BTW: the following merge to master is the trigger
>>> 
>>> commit 5363a1905b822d8ec4152b9a6fcd1bc5ecfdfb35 (HEAD -> master, 
>>> origin/master, origin/HEAD)
>>> Merge: 5604a6f22e 5dc3e8b4b9
>>> Author: Satish Balay <ba...@mcs.anl.gov>
>>> Date:   Sun Jun 9 09:22:52 2019 -0500
>>> 
>>>   Merge branch 'pr1723/tappel/extend-mumps-parameters/master' [PR #1723]
>>> 
>>> 
>>> Satish
>>> 
>>> 
>>> On Mon, 10 Jun 2019, Smith, Barry F. via petsc-dev wrote:
>>> 
>>>> I've noticed this issue with Jenkins tests recently but don't see it in 
>>>> next nightly builds
>>>> 
>>>> https://petsc-dev.org/jenkins/blue/organizations/jenkins/pj02%2Farch-jenkins-linux-gcc-pkgs-opt/detail/PR-1773/1/tests
>>>> 
>>>> perhaps related to last MUMPS release? One number seems oddly large 
>>>> 
>>>> ICNTL(38) (estimated compression rate of LU factors): 333
>>>> ---
>>>>> ICNTL(38) (estimated compression rate of LU factors): 0
>>>> 
>>>> Perhaps the test is never run in nightly but only in Jenkins, so the 
>>>> output files were not updated?
>>>> 
>>>> Or a bad report from MUMPS due to memory initialize issues? Who knows
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 
>