[petsc-dev] broken nightlybuilds (next vs next-tmp)

[Jed Brown]

Matthew Knepley <knepley at gmail.com> writes:

> On Sat, Nov 11, 2017 at 1:15 PM, Satish Balay <balay at mcs.anl.gov> wrote:
>
>> On Sat, 11 Nov 2017, Matthew Knepley wrote:
>>
>> > >
>> > > BTW: Ultimlately if you want to improve current next model - everyone
>> > > has to do a 'make alltests DIFF=$PETSC_DIR/bin/petscdiff' for atleast
>> > > one build that has relavent feature options enabled - before merging
>> > > the feature branch to next.
>> > >
>>
>> > This does not agree with my experience (I think) for bug finding. It
>> > tends to be other architectures (complex, 64-bit int, fortran) that
>> > fail for me, which means running that for many builds, and my laptop
>> > is just not capable, and furthermore that is why we have a farm of
>> > machines.
>>
>> Your laptop is just an excuse. You can do it on cg.mcs or other
>> machines. Infact you can run one of the complex or 64-bit tests
>> manually on cg.
>>
>
> And that makes my point. The time for me to login to cg, set
> everything up, and run the tests should be automated, and in fact we
> already did that for next, which is what should be used.

Merging is synchronous.  If I do

  git checkout master
  git pull
  git merge jed/risky-business
  make alltests  # works on my machine

then how do I get this merge commit to es.mcs?  Do I make that merge
commit independently?

  ssh es.mcs
  cd petsc
  git checkout master
  git pull
  git merge jed/risky-business
  make alltests PETSC_ARCH=my-int64
  make alltests PETSC_ARCH=my-complex-cxx
  ...  # works for several PETSC_ARCH on Linux with GCC
  git push

then come back to my machine and blast away the merge that I'm not going
to use?

  git reset --hard @^
  git pull

Satish and Barry, is this really the workflow you're advocating?

>   Matt
>
>
>> My point here is - there are quiet a few issues 'make alltests' would
>> have found before merge to next [and should be fixed.]

We need a make tests that takes less than five minutes that we expect
everyone to run before merging.  And probably that runs automatically
using Pipelines or Travis or whatever.  But that isn't a substitute for
'next'.

>> Sure 'next' testing with all the variations do find other various
>> issues.
>>
>> Skipping the first step - and using next for that basic testing just
>> breaks it more - and things stay broken longer [and takes everyone
>> elses time to figure out what broke next].
>>
>> And everyone thinks someone else broken next - and its stays broken
>> for weeks..
>>
>> Satish
>>
>
>
>
> -- 
> What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which their
> experiments lead.
> -- Norbert Wiener
>
> https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>