Have run_sys_tests die or give a warning if .gitmodules aren't clean

[ekluzek]

run_sys_tests runs manage_externals and sends the output to a log file. I'd like to have it either die or print a warning if there's any issues with any of the externals.

[billsacks]

This is a good idea. Here is what I'd suggest - though I'm open to alternatives:

• Add functionality to manage_externals/checkout_externals --status that checks whether the whole set of externals is in a "clean" state and does something like print a simple, easily parseable string like "OVERALL: clean" or "OVERALL: dirty". I think this would be fairly straightforward to implement once you define the semantics of "clean" or "dirty" (e.g., does a missing external qualify as "dirty"?): In this block of checkout.py: https://github.com/ESMCI/manage_externals/blob/a48558d890d46c51c2508f97aed64b5dd1716b74/manic/checkout.py#L363-L366

  you could add an additional block that does something slightly different for this new argument. I imagine something like:

  if args.status:
      # user requested status-only
      clean = True
      for comp in sorted(tree_status.keys()):
          tree_status[comp].log_status_message(args.verbose)
          clean = clean and tree_status[comp].comp_is_clean()
      if clean:
          printlog("OVERALL: clean")
      else:
          printlog("OVERALL: dirty")

  where comp_is_clean is a new function you'd need to implement in externals_status.py.

  This seems more robust than trying to parse the full screen output from a status dump, and it could be a useful feature in other contexts as well.

• Provide a flag to --run_sys_tests that allows running even with a dirty set of externals

[ekluzek]

This needs to be adjusted in light of #2443

[ekluzek]

This came up again as I made a baseline that had to be redone because of this sort of thing.

We like the idea above about an override option. I think something like

--allow-dirty

And at this point I think we just run

./bin/git-fleximod test

And die if it errors out. Which will also fail if you have a personal form for a submodule.

[ekluzek]

I think it also should maybe fail if you have uncommitted differences in your code.

So sometimes I'd want it to fail with untracked files, but that's more common to allow ...

Adding next to discuss...