-
Notifications
You must be signed in to change notification settings - Fork 13
V2 polish #1179
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
Conversation
| except OSError as e: | ||
| # no such file, permission error, etc. | ||
| # report, then continue to next attachment file | ||
| warn_and_exit_if_fail_fast_mode(str(e)) |
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 TEST_SESSION_NAME_RULE.match(value): | ||
| return value | ||
| else: | ||
| raise BadCmdLineException("--name option supports only alphabet(a-z, A-Z), number(0-9), '-', and '_'") |
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.
In version 1, the session name could be used in commands like record build, subset instead of using --session.
However, I remember there was a discussion about separating the options — one for what can be used in the session and another for display purposes.
Therefore, we decided to omit this option at the initial release. Am I wrong??
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.
Got it. That makes sense. I do want to allow users to use arbitrary string for test session display. I'm backing out that half the change now.
|
I kept one half of the change and dropped the other. @Konboi please review. |
record session --session-nameasrecord session --name. Because we got rid of implicit session creation, this option is only available at thesessioncommand, so no need for extrasessionin the option namerecord attachmentshouldn't be an unexpected situation for our CLI. It shouldn't result in a stack trace.