[petsc-dev] error in Jenkins but not nightly

[Smith, Barry F.]

> On Jun 10, 2019, at 4:31 PM, Balay, Satish <balay at 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 <balay at 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 <balay at 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
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 
>