diff --git a/smart_tests/docs/modules/resources/pages/cli-reference.adoc b/smart_tests/docs/modules/resources/pages/cli-reference.adoc index 5158216b6..373fcd37a 100644 --- a/smart_tests/docs/modules/resources/pages/cli-reference.adoc +++ b/smart_tests/docs/modules/resources/pages/cli-reference.adoc @@ -10,11 +10,11 @@ === Install -The {PRODUCT} CLI is a Python3 package that you can install from https://pypi.org/project/smart-tests/[PyPI]. +The {PRODUCT} CLI is a Python3 package available for installation from link:https://pypi.org/project/smart-tests/[PyPI]. ==== Recommended: Using uv (fastest) -We recommend using https://docs.astral.sh/uv/[uv], a fast Python package installer, for the best installation experience. +CloudBees recommends using link:https://docs.astral.sh/uv/[uv], a fast Python package installer, for the best installation experience. First, install uv: @@ -35,21 +35,21 @@ uv tool install smart-tests ==== Alternative: Using pip -You can also install the CLI using pip: +pip can also install the CLI: `pip3 install --user --upgrade smart-tests` -This creates a `~/.local/bin/smart-tests` executable that should be in your `PATH` . (See https://www.python.org/dev/peps/pep-0370/[PEP-370] for further details.) +This creates a `~/.local/bin/smart-tests` executable that the `PATH` should include. For more information, refer to link:https://www.python.org/dev/peps/pep-0370/[PEP-370]. === Authenticate -Set your API key: +Set the API key: -`export SMART_TESTS_TOKEN=your_API_key` +`export SMART_TESTS_TOKEN=<_API_key>` === Verify -Then run `smart-tests verify` in your CI environment to see if you've successfully configured the CLI. If it succeeds, you'll see a message like the one below. If you see an error message, refer to xref:resources:troubleshooting.adoc[Troubleshooting] . +Run `smart-tests verify` in the CI environment to verify successful CLI configuration. If successful, a message like the one below appears. If an error message appears, refer to xref:resources:troubleshooting.adoc[]. [source] ---- @@ -80,7 +80,7 @@ The session name specified in `smart-tests record session` must be used in subse == Command: inspect subset -Display the details of a *subset* request. See /docs/features/predictive-test-selection/#inspecting-subset-details[Subsetting your test runs] for more info. +Displays the details of a *subset* request. For more information, refer to xref:/docs/features/predictive-test-selection/#inspecting-subset-details[Subsetting your test runs]. // [generate:inspect subset] `Usage: smart-tests inspect subset [OPTIONS]` @@ -102,7 +102,7 @@ Display the details of a *subset* request. See /docs/features/predictive-test-se |=== // [/generate] -You can use `smart-tests inspect subset` to inspect the details of a specific subset, including rank and expected duration. This is useful for verifying that you passed the correct tests or test directory path(s) into `smart-tests subset` . +Use `smart-tests inspect subset` to inspect the details of a specific subset, including rank and expected duration. This is useful for verifying that `smart-tests subset` received the correct tests or test directory paths. The output from `smart-tests subset` includes a tip to run `smart-tests inspect subset` : @@ -115,23 +115,23 @@ $ smart-tests subset minitest --build 123 --session session-123 --confidence 90% Run `smart-tests inspect subset --subset-id 26876` to view full subset details ---- -Running that command will output a table containing a row for each test, including: +Running that command outputs a table containing a row for each test, including: * Rank/order * Test identifier -* Whether the test was included in the subset -* {PRODUCT}'s estimated duration for the test * Tests with a duration of `.001` seconds were not recognized by {PRODUCT} +* Whether the subset includes the test +* {PRODUCT}'s estimated duration for the test * {PRODUCT} does not recognize tests with a duration of `.001` seconds [NOTE] -- -Note that the hierarchy level of the items in the list depends on the test runner in use. +The hierarchy level of the items in the list depends on the test runner in use. -For example, since Maven can accept a list of test _classes_ as input, `smart-tests inspect subset` will output a prioritized list of test _classes_ . Similarly, since Cypress can accept a list of test _files_ as input, `smart-tests inspect subset` will output a list of prioritized test _files_ . (And so on.) +For example, since Maven can accept a list of test _classes_ as input, `smart-tests inspect subset` will output a prioritized list of test _classes_. Similarly, since Cypress can accept a list of test _files_ as input, `smart-tests inspect subset` will output a list of prioritized test _files_. (And so on.) -- == Command: record attachment -Attach log files to test session. For more information, refer to xref:send-data-to-smart-tests:record-test-results/attach-log-files.adoc[Attach log files]. +Attaches log files to a test session. For more information, refer to xref:send-data-to-smart-tests:record-test-results/attach-log-files.adoc[Attach log files]. // [generate:record attachment] `Usage: smart-tests record attachment [OPTIONS] ...` @@ -152,7 +152,7 @@ Attach log files to test session. For more information, refer to xref:send-data- // GENERATED. MODIFY IN CLI SOURCE CODE |`--session` SESSION -|Session ID obtained by calling 'smart-tests record session'. It also accepts '@path/to/file' if the session ID is stored in a file +|Session ID from calling 'smart-tests record session'. Also accepts '@path/to/file' if a file stores the session ID |Yes |=== @@ -192,19 +192,19 @@ Sends *commit* details to {PRODUCT}. Records multiple commits from repo(s). |=== // [/generate] -Commit collection happens automatically as a part of `record build` , so normally this command need not be invoked separately. It's only used for /docs/sending-data-to-smart-tests/using-the-smart-tests-cli/recording-builds-with-the-smart-tests-cli/recording-builds-from-multiple-repositories/#multiple-repositories-builtdeployed-separately-then-tested-together-eg-microservices[Multiple repositories built/deployed separately and then tested together (e.g., microservices)] . +{PRODUCT} automatically collects commits as a part of `record build`, so normally this command does not need to be invoked separately. Use it only for xref:/docs/sending-data-to-smart-tests/using-the-smart-tests-cli/recording-builds-with-the-smart-tests-cli/recording-builds-from-multiple-repositories/#multiple-repositories-builtdeployed-separately-then-tested-together-eg-microservices[Multiple repositories built/deployed separately and then tested together (e.g., microservices)]. === `--import-git-log-output` option -Related to xref:send-data-to-smart-tests:record-builds/run-under-restricted-networks.adoc[Run under restricted networks] . +Related to xref:send-data-to-smart-tests:record-builds/run-under-restricted-networks.adoc[Run under restricted networks]. -If the `--import-git-log-output` option is used, it reads the specified file for the commit data instead of reading the commits from the repository specified by `--source` . The input file should contain the output of this Git command: +When using the `--import-git-log-output` option, the command reads the specified file for the commit data instead of reading the commits from the repository specified by `--source`. The input file should contain the output of this Git command: `git log --pretty='format:{"commit": "%H", "parents": "%P", "authorEmail": "%ae", "authorTime": "%aI", "committerEmail": "%ce", "committerTime": "%cI"}' --numstat` == Command: record build -Creates a record of a xref:concepts:build.adoc[Build] in {PRODUCT}. +Creates a record of a xref:concepts:build.adoc[] in {PRODUCT}. // [generate:record build] `Usage: smart-tests record build [OPTIONS]` @@ -215,7 +215,7 @@ Creates a record of a xref:concepts:build.adoc[Build] in {PRODUCT}. // GENERATED. MODIFY IN CLI SOURCE CODE |`--branch` NAME -|Set branch name. A branch is a set of test sessions grouped and this option value will be used for a branch name. +|Set branch name. A branch is a grouped set of test sessions, and this option value sets the branch name. |No // GENERATED. MODIFY IN CLI SOURCE CODE @@ -225,7 +225,7 @@ Creates a record of a xref:concepts:build.adoc[Build] in {PRODUCT}. // GENERATED. MODIFY IN CLI SOURCE CODE |`--commit` REPO_NAME=COMMIT_HASH -|Set repository name and commit hash when you use --no-commit-collection option (can be specified multiple times) +|Set repository name and commit hash when using --no-commit-collection option (can be specified multiple times) |No // GENERATED. MODIFY IN CLI SOURCE CODE @@ -250,17 +250,17 @@ Creates a record of a xref:concepts:build.adoc[Build] in {PRODUCT}. // GENERATED. MODIFY IN CLI SOURCE CODE |`--repo-branch-map` REPO_NAME=BRANCH_NAME -|Set repository name and branch name when you use --no-commit-collection option. Please use the same repository name with a commit option (can be specified multiple times) +|Set repository name and branch name when using --no-commit-collection option. Use the same repository name with a commit option (can be specified multiple times) |No // GENERATED. MODIFY IN CLI SOURCE CODE |`--source` DIR -|Path to local Git workspace, optionally prefixed by a label. like --source path/to/ws or --source main=path/to/ws (can be specified multiple times) +|Path to local Git workspace, optionally prefixed by a label. Like --source path/to/ws or --source main=path/to/ws (can be specified multiple times) |No // GENERATED. MODIFY IN CLI SOURCE CODE |`--timestamp` TIMESTAMP -|Used to overwrite the build time when importing historical data. Note: Format must be `YYYY-MM-DDThh:mm:ssTZD` or `YYYY-MM-DDThh:mm:ss` (local timezone applied) +|Overwrites the build time when importing historical data. Note: Format must be `YYYY-MM-DDThh:mm:ssTZD` or `YYYY-MM-DDThh:mm:ss` (local timezone applied) |No |=== @@ -271,7 +271,7 @@ The act of recording a build teaches {PRODUCT} that the specified set of commits Conceptually, a build is a collection of Git repositories, each at a specific commit. `REPO_NAME` identifies each repository contributing to a build, and it needs to be stable across different builds of the same project. Good examples include: * Relative directory paths to the repository from the "workspace root," such as `src/moduleX` if they are stable. -* `GitHubOrg/GitHubRepo` slug if your repositories are on GitHub since they are also stable. +* `GitHubOrg/GitHubRepo` slug for repositories on GitHub since they are also stable. == Command: record session @@ -301,7 +301,7 @@ Creates a record of a *test session* in {PRODUCT}. // GENERATED. MODIFY IN CLI SOURCE CODE |`--no-build` -|If you want to only send test reports, please use this option +|Use this option to only send test reports |No // GENERATED. MODIFY IN CLI SOURCE CODE @@ -316,20 +316,20 @@ Creates a record of a *test session* in {PRODUCT}. // GENERATED. MODIFY IN CLI SOURCE CODE |`--test-suite` NAME -|Set test suite name. A test suite is a collection of test sessions. Setting a test suite allows you to manage data over test sessions and lineages. +|Set test suite name. A test suite is a collection of test sessions. Setting a test suite enables management of data over test sessions and lineages. |Yes // GENERATED. MODIFY IN CLI SOURCE CODE |`--timestamp` TIMESTAMP -|Used to overwrite the session time when importing historical data. Note: Format must be `YYYY-MM-DDThh:mm:ssTZD` or `YYYY-MM-DDThh:mm:ss` (local timezone applied) +|Overwrites the session time when importing historical data. Note: Format must be `YYYY-MM-DDThh:mm:ssTZD` or `YYYY-MM-DDThh:mm:ss` (local timezone applied) |No |=== // [/generate] -This command tells {PRODUCT} that you are about to begin testing a build that was been recorded earlier with the `record build` command. **This command is now mandatory** and must be executed after every `smart-tests record build` command. +This command tindicates that will begin testing a build recorded with the `record build` command. **This command is now mandatory** and must be executed after every `smart-tests record build` command. -The command outputs a string you can save for use in other commands (like smart-tests subset and smart-tests record tests) instead of `--build` . We suggest saving the value either to an environment variable or to a text file: +The command outputs a string. Save this string for use in other commands (such as smart-tests subset and smart-tests record tests) instead of `--build`. We suggest saving the value either to an environment variable or to a text file: [source] ---- @@ -351,15 +351,15 @@ smart-tests record session --build BUILD_NAME --session SESSION_NAME [OPTIONS] smart-tests record tests TESTRUNNER --session SESSION_NAME [OPTIONS] ---- -(Otherwise, the command will write a session ID to `~/.config/smart-tests/sessions/{hash}.txt` . This location may change in the future, so don't rely on it.) +(Otherwise, the command writes a session ID to `~/.config/smart-tests/sessions/{hash}.txt`. This location may change in the future, so don't rely on it.) == Command: record tests -Send *test results* for the *test session* to {PRODUCT}. +Sends *test results* for the *test session* to {PRODUCT}. [IMPORTANT] ==== -The `--session` parameter is required and must use the session name that was registered with `smart-tests record session`. +The `--session` parameter is required and must use the session name that `smart-tests record session` registered. ==== // [generate:record tests] @@ -391,7 +391,7 @@ The `--session` parameter is required and must use the session name that was reg // GENERATED. MODIFY IN CLI SOURCE CODE |`--no-base-path-inference` -|Do not guess the base path to relativize the test file paths. By default, if the test file paths are absolute file paths, it automatically guesses the repository root directory and relativize the paths. With this option, the command doesn't do this guess work. If --base-path is specified, the absolute file paths are relativized to the specified path irrelevant to this option. Use it if the guessed base path is incorrect. +|Do not guess the base path to convert the test file paths to relative paths. By default, if the test file paths are absolute file paths, the command automatically guesses the repository root directory and converts the paths to relative paths. With this option, the command skips this inference. If --base-path specifies a path, the command converts the absolute file paths to relative paths based on the path regardless of this option. Use this option if the guessed base path is incorrect. |No // GENERATED. MODIFY IN CLI SOURCE CODE @@ -401,7 +401,7 @@ The `--session` parameter is required and must use the session name that was reg // GENERATED. MODIFY IN CLI SOURCE CODE |`--session` SESSION -|Session ID obtained by calling 'smart-tests record session'. It also accepts '@path/to/file' if the session ID is stored in a file +|Session ID from calling 'smart-tests record session'. Also accepts '@path/to/file' if a file stores the session ID |Yes |=== @@ -409,113 +409,11 @@ The `--session` parameter is required and must use the session name that was reg This command reads JUnit (or similar) XML report files produced by test runners and sends them to {PRODUCT}. -Exactly how this command generates the subset and what's required to do this depends on test runners. For available supported `TESTRUNNER` , see xref:resources:integrations.adoc[Integrations] - -== Command: split-subset - -Splits an existing *subset* from {PRODUCT} into chunks. This relates to xref:features:predictive-test-selection/request-and-run-a-subset-of-tests/subset-with-the-smart-tests-cli/replace-static-parallel-suites-dynamic-parallel-subset.adoc[Replacing static parallel suites with a dynamic parallel subset] and xref:features:predictive-test-selection/request-and-run-a-subset-of-tests/subset-with-the-smart-tests-cli/zero-input-subsetting/use-groups-to-split-subsets.adoc[Using groups to split subsets] . - -`smart-tests split-subset TESTRUNNER [OPTIONS] ...` - -Intended for use with `smart-tests subset` with the `--split` option. - -=== Options for xref:features:predictive-test-selection/requesting-and-running-a-subset-of-tests/subsetting-with-the-smart-tests-cli/replacing-static-parallel-suites-dynamic-parallel-subset.adoc[Replacing static parallel suites with a dynamic parallel subset] - -[cols="1,2,1"] -|=== -|Option |Description |Required - -|`--bin BIN_NUMBER/BIN_COUNT` -|The portion of the subset to retrieve, e.g `--bin 1/3` -|Yes - -|`--rest FILE` -|Output the remainder of the subset to a file. This is useful for running the "rest of the tests" after you've run a subset. -|No - -|`--same-bin FILE` -|[Beta; Gradle only] Place tests listed in the FILE to belong to the same bin to avoid the tests running simultaneously. -|No - -|`--subset-id SUBSET-ID-STRING` -|The ID of the subset output from `smart-tests subset --split ...` (see `--split` under `subset`) -|Yes - -|`--output-exclusion-rules` -|Output a list of tests to _exclude_ instead of a list to _include_. See Zero Input Subsetting. -|No -|=== - -=== Options for xref:features:predictive-test-selection/requesting-and-running-a-subset-of-tests/subsetting-with-the-smart-tests-cli/zero-input-subsetting/using-groups-to-split-subsets.adoc[Using groups to split subsets] - -[cols="1,2,1"] -|=== -|Option |Description |Required - -|`--split-by-group` -|Splits an existing subset output into multiple files. See below. -|No - -|`--split-by-group-with-rest` -|Similar to `--split-by-group`, except remainder/rest files are also included. See below. -|No - -|`--subset-id SUBSETID` -|The ID of the subset output from `smart-tests subset --split ...` (see `--split` under `subset`) -|Yes - -|`--output-exclusion-rules` -|For use with Zero Input Subsetting. See examples below. -|No -|=== - -`*--split-by-group*` * outputs* - -When you run `smart-tests split-subset` with the `--split-by-group` option, the CLI creates several files. If you use `--output-exclusion-rules` to enable xref:features:predictive-test-selection/request-and-run-a-subset-of-tests/subset-with-the-smart-tests-cli/zero-input-subsetting/zero-input-subsetting.adoc[Zero Input Subsetting] , the behavior changes, as shown in the table below. - -|=== -|File |Default |--output-exclusion-rules - -|subset-groups.txt -|This file contains a list of the groups you must set up. -|This file contains a list of the groups you can skip entirely. - -|subset-[groupname].txt -(one file for each group) -|Each file contains the normal subset output but only for that group's tests. You can pass these files into the test process for each group. -|Each file contains the normal subset output but only for that group's tests. You can pass these files into the test process for each group. -These files will contain exclusion rules. You're supposed to exclude these tests. - -|subset-nogroup.txt -|This file contains tests that had no group assignment, if there are any. -|This file contains tests that had no group assignment, if there are any. -|=== - -`*--split-by-group-with-rest*` * outputs* - -When you run `smart-tests split-subset` with the `--split-by-group-with-rest` option, the CLI creates several files in addition to the ones described in the above table: - -|=== -|File |Default |--output-exclusion-rules - -|rest-groups.txt -|This file contains a list of the groups you don't need to set up. -|This file contains a list of the groups you can't skip. - -|rest-[groupname].txt -(one file for each group) -|Each file contains the normal --rest output, but only for that group's tests. -|Each file contains the normal --rest output, but only for that group's tests. -These files will contain exclusion rules. You're supposed to exclude these tests. - -|rest-nogroup.txt -|This file contains --rest tests that had no group assignment if there are any. -|This file contains --rest tests that had no group assignment if there are any. -|=== +Exactly how this command generates the subset and what's required to do this depends on test runners. For available supported `TESTRUNNER`, see xref:resources:integrations.adoc[Integrations] == Command: stats test-sessions -Retrieves statistics about test sessions +Retrieves statistics about test sessions. // [generate:stats test-sessions] `Usage: smart-tests stats test-sessions [OPTIONS]` @@ -526,12 +424,12 @@ Retrieves statistics about test sessions // GENERATED. MODIFY IN CLI SOURCE CODE |`--days` INT -|How many days of test sessions in the past to be stat +|Number of days of test sessions to include in statistics |No // GENERATED. MODIFY IN CLI SOURCE CODE |`--flavor` KEY=VALUE -|flavors (can be specified multiple times) +|Flavors (can be specified multiple times) |No |=== @@ -544,11 +442,11 @@ Output example: == Command: subset -Produces a subset of *tests* to pass to your test runner. +Produces a subset of *tests* to pass to the test runner. [IMPORTANT] ==== -The `--session` parameter is required and must use the session name that was registered with `smart-tests record session`. +The `--session` parameter is required and must use the session name that `smart-tests record session` registered. ==== // [generate:subset] @@ -585,12 +483,12 @@ The `--session` parameter is required and must use the session name that was reg // GENERATED. MODIFY IN CLI SOURCE CODE |`--ignore-flaky-tests-above` N -|Ignore flaky tests above the value set by this option. You can confirm flaky scores in WebApp +|Ignore flaky tests above this option's value. Flaky scores can be confirmed in WebApp |No // GENERATED. MODIFY IN CLI SOURCE CODE |`--ignore-new-tests` -|Ignore tests that were added recently. NOTICE: this option will ignore tests that you added just now as well +|Ignore tests added recently. NOTICE: This option will ignore tests just added now as well |No // GENERATED. MODIFY IN CLI SOURCE CODE @@ -610,7 +508,7 @@ The `--session` parameter is required and must use the session name that was reg // GENERATED. MODIFY IN CLI SOURCE CODE |`--no-base-path-inference` -|Do not guess the base path to relativize the test file paths. By default, if the test file paths are absolute file paths, it automatically guesses the repository root directory and relativize the paths. With this option, the command doesn't do this guess work. If --base is specified, the absolute file paths are relativized to the specified path irrelevant to this option. Use it if the guessed base path is incorrect. +|Do not guess the base path to convert the test file paths to relative paths. By default, if the test file paths are absolute file paths, the command automatically guesses the repository root directory and converts the paths to relative paths. With this option, the command skips this inference. If --base specifies a path, the command converts the absolute file paths to relative paths based on that path regardless of this option. Use this option if the guessed base path is incorrect. |No // GENERATED. MODIFY IN CLI SOURCE CODE @@ -625,12 +523,12 @@ The `--session` parameter is required and must use the session name that was reg // GENERATED. MODIFY IN CLI SOURCE CODE |`--rest` FILE -|Output the subset remainder to a file, e.g. --rest=remainder.txt +|Output the subset remainder to a file, for example --rest=remainder.txt |No // GENERATED. MODIFY IN CLI SOURCE CODE |`--session` SESSION -|Session ID obtained by calling 'smart-tests record session'. It also accepts '@path/to/file' if the session ID is stored in a file +|Session ID from calling 'smart-tests record session'. Also accepts '@path/to/file' if a file stores the session ID |Yes // GENERATED. MODIFY IN CLI SOURCE CODE @@ -646,43 +544,43 @@ The `--session` parameter is required and must use the session name that was reg |=== // [/generate] -Exactly how this command generates the subset and what's required to do this depends on test runners. For available supported `TESTRUNNER` s, see xref:resources:integrations.adoc[Integrations] . +Exactly how this command generates the subset and what's required to do this depends on test runners. For available supported `TESTRUNNER`, refer to xref:resources:integrations.adoc[]. -When none of `--target` , `--time` , and `--confidence` is specified, {PRODUCT} chooses the subset target. This is convenient on the initial setup when you are unsure what the subset size should be. Later, you can choose the right target after you see the statistics of your test suite and potential time-savings based on the {PRODUCT} accumulated data. +Without `--target`, `--time`, or `--confidence`, {PRODUCT} chooses the subset target. This is convenient during initial setup when subset size is uncertain. Later, you can choose the right target after viewing test suite statistics and potential time-savings based on the {PRODUCT} accumulated data. == Command: verify -Verify that the CLI can communicate with the {PRODUCT} service and that you're authenticated properly. +Verifies that the CLI can communicate with the {PRODUCT} service and that the authentication configuration is correct. // [generate:verify] `Usage: smart-tests verify` // [/generate] -To avoid disrupting your CI/test process, the {PRODUCT} CLI is designed to tolerate and recover from service disruptions and other recoverable error conditions by falling back to no-op. This is an intentional design, but the downside is that such transparent failures can make troubleshooting difficult. +To avoid disrupting the CI/test process, the {PRODUCT} CLI tolerates and recovers from service disruptions and other recoverable error conditions by falling back to no-op. This intentional design has a downside; transparent failures can make troubleshooting difficult. -Therefore, we recommend you keep `smart-tests verify || true` in a recognizable spot in your CI process. This way, when you suspect a problem in {PRODUCT}, you can check the output of this command as a starting point. +Therefore, we recommend you keep `smart-tests verify || true` in a recognizable spot in the CI process. This way, when suspecting a problem in {PRODUCT}, you can check the output of this command as a starting point. == Global options [NOTE] -- -These global options can be placed after the subcommand, for example `smart-tests verify --log-level audit` +Place these global options after the subcommand, for example `smart-tests verify --log-level audit`. -- === --dry-run -The dry-run mode does not actually send a payload to the server, and it is helpful to check the behavior. You can also see which APIs will be requested and their payload contents in the output. +The dry-run mode does not actually send a payload to the server, and it is helpful to check the behavior. The output also shows which APIs the command will request and their payload contents. -The payload contents will be output as an audit log, so if the log level is higher than the audit level, it will be forced to be set to the audit level. +The command outputs the payload contents as an audit log. If the log level is higher than the audit level, the command forces it to the audit level. -Strictly speaking, it does not mean no requests will be sent, but GET requests with no payload data or side effects may be sent. This is because sometimes the response data from the GET request is needed to assemble subsequent requests. +Strictly speaking, it does not mean the command sends no requests, but the command may send GET requests with no payload data or side effects. This is because sometimes the command needs the response data from the GET request to assemble subsequent requests. === --log-level -You can use the `--log-level` option to output extra information from each command. +Use the `--log-level` option to output extra information from each command. -`--log-level audit` is particularly useful if you want to see exactly what data gets passed to {PRODUCT} when you run CLI commands. For example: +`--log-level audit` is particularly useful if you want to see exactly what data gets passed to {PRODUCT} when running CLI commands. For example: [source] ---- @@ -693,18 +591,18 @@ AUDIT:smart-tests:send request method:post path:/intake/organizations/example/wo === --plugins -You can use the `--plugins` option to tell the CLI where to look for custom profiles/plugins. +Use the `--plugins` option to tell the CLI where to look for custom profiles/plugins. -For example, if you have developed (or been provided) a custom profile file named `myProfile.py` , place that file in the directory of your choosing (e.g., `~/smart-tests-plugins` ) and use it like this: +For example, with a custom profile file named `myProfile.py`, place that file in a directory (for example, `~/smart-tests-plugins`) and use it like this: `smart-tests --plugins ~/smart-tests-plugins record tests myProfile --build $BUILD --session $SESSION /path/to/reports` -Since `--plugins` is a global option, make sure to place it right after `smart-tests` but before `subset` or `record` in your command. +Since `--plugins` is a global option, make sure to place it right after `smart-tests` but before `subset` or `record` in the command. === --skip-cert-verification This option instructs the CLI to bypass the SSL certificate verification. This is inteded to be an escape hatch in case the system's Python setup is broken/incomplete. -Alternatively, you can set the `SMART_TESTS_SKIP_CERT_VERIFICATION` environment variable to any value to have the same effect. This is more convenient if you want this behaviour across the board, instead of just one invocation. +Alternatively, set the `SMART_TESTS_SKIP_CERT_VERIFICATION` environment variable to any value to have the same effect. This is more convenient for applying this behavior across the board, instead of just one invocation. -This flag will make your communication with {PRODUCT} less secure (for example, you can be vulnerable to a DNS spoofing attack). Use it with a caution. +This flag will make your communication with {PRODUCT} less secure (for example, this creates vulnerability to a DNS spoofing attack). Use with a caution.