De-duplicate multiple-pipeline-capture/playback #532
Conversation
No code change, pure rename to help git track the rename. Cannot add a multiple-pipeline-capture.sh wrapper in this commit too otherwise git fails to track the rename which breaks git blame, cherry-pick, merge etc. Next commit. First step towards converging with multiple-pipeline-playback.sh Preferring -capture over -playback because capture has more detailed history. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
|
https://sof-ci.01.org/softestpr/PR532/build427/devicetest/ passed for the most part but this change confused Jenkins which timed out. I think this because this change makes the test looks like a "Sub-Test", so the last line printed is: |
Not in previous commit otherwise git fails to track the rename which breaks git blame, cherry-pick, merge etc. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
multiple-pipeline-capture.sh is now multiple-pipeline.sh -f c Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Finally removes massive duplication with multiple-pipeline-capture.sh Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Fixed in https://sof-ci.01.org/softestpr/PR532/build438/devicetest/ thanks to |
| OPT_OPT_lst['f']='first' | ||
| OPT_DESC_lst['f']='Fill either playback (p) or capture (c) first' | ||
| OPT_PARM_lst['f']=1 OPT_VALUE_lst['f']='p' | ||
|
|
There was a problem hiding this comment.
@marc-hb The option f means first, that's good for now. In fact, I want one more option for all pipelines, then the first may not be proper.
Good point, how about I'm going to merge this because it's been submitted 7 days ago, should make no functional change and it's blocking further, actual functional changes. I can submit a follow-up commit that just renames the option as the option does not have any external user yet. |
2 participants
4 commits, commits MUST be reviewed individually otherwise github shows a very large code change when it's actually quite small.