Update MOOSE and Crane submodules

[dschwen]

Closes #61

[cticenhour]

Will merge when testing completes

[cticenhour]

Thanks @dschwen!

[moosebuild]

Job Mac Test on 0452b45 : invalidated by @cticenhour

Environment did not initialize correctly

[dschwen]

@cticenhour this uses an outdated libmesh conda package. The updated moose submodule has an updated libmesh submodule which should trigger a conda package rebuild. This might not be in your test recipe and you might have to wait until the libmesh conda package is released. This might happen once the changes in moose hit master (Jason will know that).

[cticenhour]

Yes, you're right - I noticed after my invalidate. I won't get a libmesh package update for these recipes until those changes hit master.

@milljm -- Do I need to temporarily allow Zapdos to fail on the External App Tests target so that these changes can move on to master (after the other failures are fixed)?

[lindsayad]

Oh wow this is a good one...a Zapdos PR that depends on a MOOSE update which we can do because we have a MOOSE submodule...but that we can't do because we don't actually test against the libmesh hash that is in the MOOSE submodule... 🤣

[lindsayad]

More incentive to stop using conda libmesh for CIVET testing

[cticenhour]

Or have a package generated earlier for a libmesh update and then used for testing, with the final channel transition occurring in master. I suppose that would require another channel?

[fdkong]

Oh wow this is a good one...a Zapdos PR that depends on a MOOSE update which we can do because we have a MOOSE submodule...but that we can't do because we don't actually test against the libmesh hash that is in the MOOSE submodule... 🤣

Wow, MOOSE update will depend on a PETSc submodule update that we can control since it is a moose submodule, but we can not since we do not test against the petsc submodule hash. So civet should stop using conda-petsc 🤣

[lindsayad]

We should have ./update_and_rebuild_everything.sh that starts with gcc submodule and finishes with libmesh :-)

…

On Fri, May 29, 2020 at 8:42 AM Fande Kong ***@***.***> wrote: Oh wow this is a good one...a Zapdos PR that depends on a MOOSE update which we can do because we have a MOOSE submodule...but that we can't do because we don't actually test against the libmesh hash that is in the MOOSE submodule... 🤣 Wow, MOOSE update will depend on a PETSc submodule update that we can control since it is a moose submodule, but we can not since we do not test against the petsc submodule hash. So civet should stop using conda-petsc 🤣 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#62 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACOGA4GN5VAPGQFQLYAYQETRT7JWRANCNFSM4NNMZ3JA> .

[milljm]

I suppose you can revert the changes @cticenhour did to Zapdos civet recipes (so it does not use conda).

I can do that if you all wish.

[lindsayad]

:-( I guess so. I really like what you did with the "build Linux stack/build Mac stack" for MOOSE testing, but it probably doesn't make sense to do it for application testing...? Maybe it's just easier to build libmesh

[dschwen]

You could add an additional allowed to fail build with conda recipe. But for testing the submodule should be the gold standard.

[lindsayad]

[cticenhour]

FYI the changes to Zapdos testing was reverted for now until a better solution for conda testing is in place. Invalidating to redo the testing.

[cticenhour]

Intermittent failure in Mac Test occurs during Fetch and Branch:

BUILD_ROOT/zapdos/: git pull --no-ff [email protected]:dschwen/zapdos.git api_update_61
From github.com:dschwen/zapdos
 * branch            api_update_61 -> FETCH_HEAD
Fetching submodule crane
From github.com:lcpp-org/crane
   8a5fd5b..581cb44  master     -> origin/master
Fetching submodule moose
From github.com:idaholab/moose
   ce7162a053..0289ba37e8  devel      -> origin/devel
   10b79e5667..c4d71de1ea  master     -> origin/master
   e470dd3296..0f3c82da44  next       -> origin/next
 * [new branch]            revert-15355-deim-test-problem -> origin/revert-15355-deim-test-problem
Could not access submodule 'large_media'Fetching submodule moose/libmesh
fatal: cannot chdir to '../../../../../moose/libmesh': No such file or directory
fatal: cannot chdir to '../../../../../moose/libmesh': No such file or directory
Deleting repository in an attempt to fix an un-recoverable git issue
Removing /opt/civet/build_0/zapdos

Any idea why git is getting confused here? I should say it's not the first time I've seen it (we just had more important failures to deal with)

[cticenhour]

After discussions with Jason, this seems to be a git issue happening on other PRs around MOOSE-land, not just Zapdos. I am going to merge.