Set MAYA_APP_DIR for each test, pointing to unique folders. #1163
Conversation
| # Set a temporary folder path for the MAYA_APP_DIR in which the | ||
| # maya profile will be created. | ||
| # Note: replace bad chars in test_name with _. | ||
| string(REGEX REPLACE "[:<>\|]" "_" SANITIZED_TEST_NAME ${test_name}) | ||
| set(MAYA_APP_TEMP_DIR "${CMAKE_BINARY_DIR}/test/Temporary/${SANITIZED_TEST_NAME}") | ||
| # Note: ${WORKING_DIR} can point to the source folder, so don't use it | ||
| # in any env var that will write files (such as MAYA_APP_DIR). | ||
| set_property(TEST "${test_name}" APPEND PROPERTY ENVIRONMENT | ||
| "MAYA_APP_DIR=${MAYA_APP_TEMP_DIR}") | ||
| file(MAKE_DIRECTORY ${MAYA_APP_TEMP_DIR}) |
There was a problem hiding this comment.
This will put all the maya profiles into unique folders (by test name) in the folder ".../test/Temporary". This way you can easily delete them all if needed. I make sure to create the folders here as well. Actually the tail part of the folder will be created by Maya, but its easier to just make sure they are all created here.
Krystian pointed me to your attempt at this in the past and said you had some problems with test failures. I believe that could be because you used ${WORKING_DIR}, which sometimes points to the source folder (see line 98). Creating test files in the source folder would not be good. I'm not sure why WORKING_DIR would even point to the source folder - that seems incorrect.
I ran this multiple times on both my Windows and Linux machines and ran two of our internal builds on all platforms. I didn't see any test failures.
There are two other places where MAYA_APP_DIR is used directly. In those cases it will be set to a temporary folder created in the temp directory.
There was a problem hiding this comment.
The problem we saw earlier wasn't direct test failures, per-se... but just that the tests ran over a timeout when run in the preflight context. I never had any test failures when running locally, or really noticed much of a time difference when running the tests with the MAYA_APP_DIR set... but apparently it made a difference in whatever environment pre-flight was running.
Which isn't to say that your changes won't fix whatever the cause of that slowdown was - maybe it was something related to running out of the WORKING_DIR? But just be on the watch-out for it, I guess!
Anyway, I'll assign the bot user to get the tests to run, so hopefully we'll know soon!
There was a problem hiding this comment.
Okay good to know. What we've seen is random test errors related to not being able to write to the MAYA_APP_DIR (because by default it will be set to the user folder). This change makes sure that its always in a writeable location (the build folder).
This change by itself won't have any impact on the test performance. In our internal build systems we have all the Linux tests set to run serial (while Windows/OSX run in parallel). So currently the Linux tests take anywhere from 30-40 mins. We had set Linux to serial because were were seeing all sorts of unexplained random failures. But we now believe that was due to multiple tests trying to access the user prefs. This change gives each test its own user prefs folder so internally (in another change) I can enable running Linux tests in parallel (reducing the time down to 5 mins).
There was a problem hiding this comment.
Ooo - does that mean that the preflight checks will get faster? If so:
| # Set a temporary folder path for the MAYA_APP_DIR in which the | ||
| # maya profile will be created. | ||
| # Note: replace bad chars in test_name with _. | ||
| string(REGEX REPLACE "[:<>\|]" "_" SANITIZED_TEST_NAME ${test_name}) | ||
| set(MAYA_APP_TEMP_DIR "${CMAKE_BINARY_DIR}/test/Temporary/${SANITIZED_TEST_NAME}") | ||
| # Note: ${WORKING_DIR} can point to the source folder, so don't use it | ||
| # in any env var that will write files (such as MAYA_APP_DIR). | ||
| set_property(TEST "${test_name}" APPEND PROPERTY ENVIRONMENT | ||
| "MAYA_APP_DIR=${MAYA_APP_TEMP_DIR}") | ||
| file(MAKE_DIRECTORY ${MAYA_APP_TEMP_DIR}) |
There was a problem hiding this comment.
The problem we saw earlier wasn't direct test failures, per-se... but just that the tests ran over a timeout when run in the preflight context. I never had any test failures when running locally, or really noticed much of a time difference when running the tests with the MAYA_APP_DIR set... but apparently it made a difference in whatever environment pre-flight was running.
Which isn't to say that your changes won't fix whatever the cause of that slowdown was - maybe it was something related to running out of the WORKING_DIR? But just be on the watch-out for it, I guess!
Anyway, I'll assign the bot user to get the tests to run, so hopefully we'll know soon!
seando-adsk
added
ready-for-merge
seando-adsk
added
ready-for-merge
No description provided.