-
Notifications
You must be signed in to change notification settings - Fork 185
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
Testing: shell script per test #2865
Conversation
clang-tidy review says "All clean, LGTM! 👍" |
@daljit46: What are the chances of getting some help on the |
👍 Happy to help. I'll try to have a go at this today. |
Why do we need to copy the script in the build directory? |
clang-tidy review says "All clean, LGTM! 👍" |
Just made some minimal changes to current CMake scripts to run binary tests. I relied on globbing to parse the files inside each folder, but we probably best to not use it in the final implementation. |
If we don't rely on globbing, we could do this in CMake directly. IMO, that would be cleaner. |
Globbing is disabled and each test is manually listed in the corresponding CMakeLists.txt. Labels can be specified as extra arguments to the add_bash_binary_tests function
clang-tidy review says "All clean, LGTM! 👍" |
Previously, the lines of a file were read, and each was used to form a single test invocation, where the contents of the test were just a part of the test string. Here, where an individual test can be a multi-line bash script, my thinking was that those files would therefore be copied into the build directory, and the test string would involve executing that shell script. Not saying this absolutely has to be the case, it's just what I had expected would be your recommendation.
So my plan here is different. The set of tests for a given command are not guaranteed to be executed all together, or in any particular order. Each test needs to be possible to run in isolation, and should ideally clean up after itself.
|
Put some effort into this one as I wish to be able to make use of this change to verify and finalise changes elsewhere.
|
Yes, that's quite verbose indeed. I just pushed a change that works around this problem by adding another level of indirection. Inspired by this StackOverflow post, I've added a wrapper
Yes, that issue is tracked in #2855. I haven't completed that PR yet as we have a lot of ongoing changes to the testing logic, but I will do so when things get more stable. |
This allows to get rid of the cleanup tests and instead execute a custom CMake script which will execute a given bash test. The script takes care of cleaning up regardless whether the test passes or not.
- Run all test commands with -e flag to exit script as soon as any underlying command fails. - Rename add_bash_tests() to add_bash_test() given that there is now only one test per file rather than many. - For tests that ensure proper failure of a command, check that the appropriate error message is issued. - Some newline fixes within test scripts. - Add -force flag to some tests. - Import changes to reference test data for fixel2voxel and sh2power.
The cleanup is for some reason not working. Have masked it with |
I can at least confirm that outside of the |
5f081b4
to
77cc0d7
Compare
7fbc510
to
e0fa479
Compare
This reverts commit 9d2315d.
Ok, so I spent a lot of time figuring out why CTest is unable to execute
Then we can move Additionally, I just remembered that in #2437 we decided to disable npy tests on Windows because installing numpy was tricky. Here, we will run into the same problems so I'm not even sure if we want to make the effort to make the tests work on MSYS2. |
Resolves CI testing issues discussed in #2865.
I was getting some rather puzzling results myself yesterday. Wasn't able to sufficiently wrap my head around exactly what was going on to be able to make modifications or even post anything of use here. There's clearly something going very wrong with the paths, given after your changes the MSYS2 CI produced this: On my own Windows system, with a clean build, I now have all tests failing...
If you think it would be a worthwhile change in its own right, I'd be happy for the change to be made. I think that for the sake of getting this PR merged to facilitate progressing with others I'll do something different, but there's clearly something more fundamental going wrong that would be preferable to resolve longer term.
I had recollection of implementing code in all relevant commands to support the prospect of What I'm hoping will work instead in 36f333b is to not generate those tests in the first place if |
36f333b doesn't work:
Could do a sneaky sneaky and omit the NPY tests based on |
On 1f4b8be:
|
Attempting to resolve residual errors in MSYS2 CI in #2865.
This is necessary to pass tests on MSYS2, as tests involving execution of mrinfo need to invoke the MRtrix3 command mrinfo rather than the Windows command of the same name.
Santiziers workflow needs to be update after #2865
Sanitizers workflow needs to be updated after #2865
Committing what I've generated thus far to a draft PR; likely not able to finish off this week.
Closes #2789.
Supersedes #2825.
While this took a decent amount of time to work though, I'm hoping that it will make the addition of new tests a bit more accessible: one can add header comments explaining what the test does & why, and can actually make use of newline characters.
Previous behaviour:
Desired behaviour:
trap
to clean up any temporary files afterwards regardless of outcomeEdit: Alternative solution for this purpose under development
Ideally have some string included in the comments at the head of the shell script file that can be parsed by
cmake
to discover that that test should have that label attributed to it.Edit: Deferred to Update testing README #2855.