Skip to content
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

Documentation request: document all automatic variable replacements available #134

Open
hagertnl opened this issue Sep 28, 2023 · 1 comment
Labels
documentation Improvements or additions to documentation

Comments

@hagertnl
Copy link
Contributor

The harness has many automatic replacements that aren't derived from rgt_test_input.ini. For example - working_dir, scripts_dir, results_dir.
I think we need to document all the possibilities, because I am even surprised sometimes by new replacements.

@hagertnl hagertnl added the documentation Improvements or additions to documentation label Sep 28, 2023
@hagertnl
Copy link
Contributor Author

hagertnl commented Oct 2, 2023

In addition, we should also document all automatically-created test-specific environment variables. We have documented that the variables from machine.ini get added to the environment -- good. But we also have several variables that seem to be created by the harness automatically like

RGT_TEST_BUILD_DIR
RGT_TEST_SCRIPTS_DIR
RGT_TEST_WORK_DIR
RGT_TEST_RUNARCHIVE_DIR
RGT_TEST_STATUS_DIR
RGT_APP_SOURCE_DIR

And in our current Slurm template that we provide, we ultimately duplicate these fields by using the replacements of __working_dir__, __results_dir__, etc.

I think we might want to consider using these fields in the template and even in check scripts.
Rationale:

  • I'm thinking of a case where the user runs something like "set_harness_environment.py" from within a test's Run_Archive directory, and "set_harness_environment.py" sets the RGT_TEST_* variables. Now, the user could potentially run the check/report scripts by hand (or run the check_executable_driver.py script more easily).

One pitfall that comes to mind:

  • Paths wouldn't be hard-coded within the job script

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

1 participant