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

twister: add instance name as default parameter #81389

Closed

Conversation

hakehuang
Copy link
Collaborator

add testinstance name as default parameter to
customer scripts

@@ -694,7 +694,10 @@ def handle(self, harness):
timeout = 30
if script_param:
timeout = script_param.get("pre_script_timeout", timeout)
self.run_custom_script(pre_script, timeout)
pre_script_cmd = ([pre_script] +
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what if with this change we also allow these *script properties to convey a script command line with parameters,
not just a script file path as it is now, but doing like this

pre_script_cmd = (pre_script.split() +
                              [self.instance.name]
                             )

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe instead of passing the instance name every time to those scripts, better to allow user to add custom parameters in hardware map, e.g.
pre_script: '<PATH>/script.py --input platform_name'
and better to modify run_custom_script method:

  • just add shell=True to subprocess.Popen
  • or use shlex.split(script) to safely split input parameters (to avoid issues with shell injections)

If you add additional parameter to every call, you definitely must to document it (as @golowanow requested), because some of downstream users can use custom scripts that do not allow additional parameters

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. platform name is not enough, most of time we need to know the testinstance name to decide how to run pre_script.
  2. shell-True sometime does not work well in a cloud system.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

most of time we need to know the testinstance name to decide how to run pre_script.

I still don't think it is good idea to pass this info every time to the pre/post scripts. If you need something extra in your internal scripts, you can just read it from build folder (name of directory consists a platform name and test name ... or just take it from CMakeCache.txt or other build artefact).

shell-True sometime does not work well in a cloud system.

try to use split to pass a list to subprocess

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we have 8 instance running, how do I know which one is the current directory to parse?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still don't think it is good idea to pass this info every time to the pre/post scripts. If you need something extra in your internal scripts, you can just read it from build folder (name of directory consists a platform name and test name ... or just take it from CMakeCache.txt or other build artefact).

By parsing the current build system to get the instance name, this costs more. and the instance name is so far the only thing we need to identify, as we know the platform + instance_name, it will uniquely identify the test case context.

@@ -694,7 +694,10 @@ def handle(self, harness):
timeout = 30
if script_param:
timeout = script_param.get("pre_script_timeout", timeout)
self.run_custom_script(pre_script, timeout)
pre_script_cmd = ([pre_script] +
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will add

add testinstance name as default parameter to
customer scripts

Signed-off-by: Hake Huang <[email protected]>
update test_handler for new parameters

Signed-off-by: Hake Huang <[email protected]>
No scripts will have a default parameter testinstance.name
also add twister document for scripts

Signed-off-by: Hake Huang <[email protected]>
"post_script_timeout": 100
"post_flash_timeout": 100

also a default patameter <testinstance.name> will be pass as fist parameter for scripts
Copy link
Member

@golowanow golowanow Nov 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hakehuang, to be on the same page: why you need the instance name to pass to scripts ?

btw. it is platform/suite_path/suite_name where platform prefix is not 'normalized' (it is in HWMv2 format), whereas suite_path might be excluded with --no-detailed-test-id option.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we have a platform, for security reasons, it need pre-load different security blobs to board first, before run test. @golowanow .

btw. it is platform/suite_path/suite_name where platform prefix is not 'normalized' (it is in HWMv2 format), whereas suite_path might be excluded with --no-detailed-test-id option.

it is not an issue at my case, as per_script is always defined in platform level, so we know which platform it is running already. and suite_path is not need usually, as pre_script does not always go with the build but run

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is not an issue at my case, as per_script is always defined in platform level, so we know which platform it is running already. and suite_path is not need usually, as pre_script does not always go with the build but run

so in your use case the parameter it is just for suite_name actually ?

well, I think it is a quite frequent situation when the same flash- script is re-used with different platforms/variants (currently that can be solved creating links to the same script file with different names), and the better and general solution would be to call these scripts with a basic set of expected parameters (like what Twister has --platform, --scenario, etc.) in addition to the command line from the map file the script is called with.

Copy link
Collaborator Author

@hakehuang hakehuang Nov 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the platform information is already contained in the map.yaml, which pre/post scripts rely on. and this could be fixed to the only interface.

@hakehuang hakehuang requested a review from golowanow December 9, 2024 07:23
@hakehuang
Copy link
Collaborator Author

@golowanow @gchwier @LukaszMrugala @nashif , please help to review, this is to unified the post and pre script interface for different cases.

Copy link
Member

@nashif nashif left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please review and fix your commit messages, they have a few typos.
Also, please add more information and rationale in the commits and documentation how the test instance name will be used.

I do not think it is a good idea to rely on twister internal variables for the scripts (test instance name), this should be something that is visible at the test definition, i.e. yaml file, suite name, scenario etc. and not an internal twister variable that is subject to change and is not known at the time of writing the test.


* post_flash_script: <path to pre script>

each of above scripts can have timeout defined as below in hardwar map file by script_param
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hardware map

@hakehuang
Copy link
Collaborator Author

there is another approach to use the yaml file to control the script, so I close this PR.

@hakehuang hakehuang closed this Jan 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants