-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add prototype testing of remote functionality #3817
Conversation
0687faf
to
17bdc86
Compare
It looks great from the cmake/ctest perspective, I suppose that this will be linux/osx only? You might want to add these test is not
If we were to double the BP tests, this can really hinder performance in our MPI enabled builds since they already take 20-40mins to pass. I suggest to add them to the non-mpi builds (serial) a good candidate would be: |
* ci: fix codeql ignore path
Add Memory Selection to SST, and prototype a mechanism for running st…
@pnorbert This is a first-cut at how we might test the Remote server functionality in CI.
If you build this and do something like:
ctest -V -R REMOTE
You'll see that the CMake FIXTURES stuff is setup so that it starts a remote server before it runs a set of tests that require it and shuts it down afterwards. The server itself has to go into the background and close all of its FDs in order for ctest to continue after starting it. The "shutdown" test sends a message to the server asking it to die and in response the server sends its statistics (files opened, bytes read and operation count, for both Get()-level and transport-level operations). These are output from the shutdown test (but you can only see them if you've turned on ctest verbosity:
Right now I've just set this up for a single test, but arguably we need to do this for all of the BP engine tests and maybe all of the staging-common tests too. This is just a first cut, so there are deficiencies and non-optimal stuff. For example, right now both server and client are looking at the same file, so if the client wasn't doing remote stuff but was just reading data directly we'd only know it by noticing that the output of the server didn't show operations. But it's a start.
@vicentebolea You may be off already, or close to it, but I wanted to ask if this looked OK from a CMake/Ctest point of view. Also, how much slack do we have on CI timing now? If we essentially double the number of BP tests we're running by doing them both as we have been and also with the server involved, are we doing to hit CI timeouts?