search

MESAHub / mesa_test

Command line tool for running the MESA test suite and uploading results to MESATestHub
MIT License
2 stars 3 forks source link

Remove call to version_number from submit commands #9

Closed jschwab closed 6 years ago

jschwab commented 6 years ago

The commands submit_one, submit_all seem to re-fetch the version_number. I don't think this is necessary since the version number is already recorded in test_results.yml.

Is it easy to eliminate this call? Calls to svnversion on our cluster can take a long time to return (for reasons I don't understand), so sometimes it takes ~5 min for submit_all to complete.

(I'm basing this on the fact that when I interrupted an apparently stalled submit_all, the backtrace indicated it was in version_number/ svnversion.)

wmwolf commented 6 years ago

SVN business has been reworked. If use_svn is set to true in the instantiation of the Mesa object, then the author, commit message, and version are all obtained then and remembered. Further calls to version_number will either get the saved one from svn or fall back on what's in the data directory.

In the command line interface, you can shut down svn niceties with the --no-svn option on any subcommand that would normally need to find the version. This should prevent any calls to svn log or svnversion.

jschwab commented 6 years ago

I just got around to trying this and when I do test_one I get the backtrace

hyades: ~$ mesa_test test_one --force --no-submit /pfs/jschwab/mesa-svn-test 1
/pfs/home/jschwab/modules/ruby/lib/ruby/gems/2.4.0/gems/mesa_test-0.0.24/lib/mesa_test.rb:547:in ``': No such file or directory - svn (Errno::ENOENT)
        from /pfs/home/jschwab/modules/ruby/lib/ruby/gems/2.4.0/gems/mesa_test-0.0.24/lib/mesa_test.rb:547:in `log_entry'
        from /pfs/home/jschwab/modules/ruby/lib/ruby/gems/2.4.0/gems/mesa_test-0.0.24/lib/mesa_test.rb:553:in `load_svn_data'
        from /pfs/home/jschwab/modules/ruby/lib/ruby/gems/2.4.0/gems/mesa_test-0.0.24/lib/mesa_test.rb:532:in `initialize'
        from /pfs/home/jschwab/modules/ruby/lib/ruby/gems/2.4.0/gems/mesa_test-0.0.24/bin/mesa_test:468:in `new'
        from /pfs/home/jschwab/modules/ruby/lib/ruby/gems/2.4.0/gems/mesa_test-0.0.24/bin/mesa_test:468:in `create_and_check_mesa'
        from /pfs/home/jschwab/modules/ruby/lib/ruby/gems/2.4.0/gems/mesa_test-0.0.24/bin/mesa_test:62:in `test_one'
        from /pfs/home/jschwab/modules/ruby/lib/ruby/gems/2.4.0/gems/thor-0.20.0/lib/thor/command.rb:27:in `run'
        from /pfs/home/jschwab/modules/ruby/lib/ruby/gems/2.4.0/gems/thor-0.20.0/lib/thor/invocation.rb:126:in `invoke_command'
        from /pfs/home/jschwab/modules/ruby/lib/ruby/gems/2.4.0/gems/thor-0.20.0/lib/thor.rb:387:in `dispatch'
        from /pfs/home/jschwab/modules/ruby/lib/ruby/gems/2.4.0/gems/thor-0.20.0/lib/thor/base.rb:466:in `start'
        from /pfs/home/jschwab/modules/ruby/lib/ruby/gems/2.4.0/gems/mesa_test-0.0.24/bin/mesa_test:505:in `<top (required)>'
        from /pfs/home/jschwab/modules/ruby/bin/mesa_test:23:in `load'
        from /pfs/home/jschwab/modules/ruby/bin/mesa_test:23:in `<main>'

but as far as I can tell test_one doesn't support the new --no-svn option.

Sorry for making an issue that won't die. Our cluster is weird.

wmwolf commented 6 years ago

Back from the dead... I was running into a similar issue after evidently letting this fall through the cracks. The problem (which shouldn't be a problem, at least on my workstation) arose in instantiating the submitter, which re-ran the svn commands to gather information. This shouldn't be necessary if they have already been gathered.

I added an additional conditional that hopefully solves this, where the svn calls are only made if use_svn was set to true (this is old) AND if svn_version hasn't already been set. This is live as of 0.2.3.

Also at some point it looks like I did add the --svn/--no-svn option to test_one, so maybe that already solved this problem for you.

Let me know if this works, or if you found another way around in my months of abandonment.

jschwab commented 6 years ago

I think I just stopped trying to submit single tests :) Our cluster has had all sorts of issues so I haven't been running the test suite there regularly.

Thanks for the changes. I'll close this and re-open if further issues arise.