[feat] Lazy evaluation of job-related attributes and environments #961
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces two major enhancements.
Lazy evaluation of the job-related attributes
The job associated with the test is only minimally created inside
setup(). Any attributes related to its run configuration (e.g.,num_tasks,num_tasks_per_nodeetc.) are set when preparing the job script and just before launching the test. This change required that these attributes become writeable inJob's interface.This enhancement allows you to set the
num_tasksof a test based on the current partition or the environment in a cleaner way anytime after setup. For example:In case of flexible tests, the test's
num_tasksattribute is set to the actual number of tasks assigned to it, after the test has been launched. This eliminates the need of defining a separate sanity function to retrieve the number of tasks:Re-evaluate the test's environment whenever needed
The mechanism of loading environments has changed completely.
Environmentobjects are now really immutable: they are just placeholders for modules and environment variables. They don't carry any state. Responsible for loading environments is theload(*environs)free function. This function returns a tuple consisting of an environment snapshot just before loadingenvironsand the commands needed to load the environments. There is no explicit mechanism for unloading an environment as in the past. Instead, an environment or a set of environments are implicitly unloaded by restoring the environment snapshot returned by theload()function.There is also the
emit_load_commands(*environs)function, which essentially loadsenvirons, restores the original environment and returns the required load commands. In the past this was accomplished by the_setup_environ()method ofRegressionTestand the internal state of theEnvironment. Now, every timeemit_load_commands(*environs)is called, all the environments will be loaded and the command sequence will be recorded. In addition to that, we construct a new user environment (fromself.modulesandself.variables) before the build and run phase of the pipeline. This allows a user to define different compilation and running environments. An example follows:This will define
OMP_NUM_THREADSonly inside the generated job script and not in the build phase.Due to this feature, this PR fixes #58.