-
Notifications
You must be signed in to change notification settings - Fork 6.9k
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
Conversation
@@ -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] + |
There was a problem hiding this comment.
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]
)
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- platform name is not enough, most of time we need to know the testinstance name to decide how to run pre_script.
- shell-True sometime does not work well in a cloud system.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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] + |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please document this new behavior for --pre-script
command
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will add
35711ef
to
93df5ec
Compare
93df5ec
to
ad2417d
Compare
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]>
ad2417d
to
1dd532e
Compare
"post_script_timeout": 100 | ||
"post_flash_timeout": 100 | ||
|
||
also a default patameter <testinstance.name> will be pass as fist parameter for scripts |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
whereplatform
prefix is not 'normalized' (it is in HWMv2 format), whereassuite_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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
@golowanow @gchwier @LukaszMrugala @nashif , please help to review, this is to unified the post and pre script interface for different cases. |
There was a problem hiding this 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hardware map
there is another approach to use the yaml file to control the script, so I close this PR. |
add testinstance name as default parameter to
customer scripts