[update] Clarify messaging around which runners are updating #87
Assignees
Labels
enhancement
New feature or request
Comments
tsibley
added a commit
that referenced
this issue
Sep 13, 2022
With no arguments, the default runtime is updated. The name of another runtime to update instead may be provided as an argument. In practice this isn't much of a behaviour change because only one runtime currently supports updating (Docker); the others (native, AWS Batch) just pass. Existing users are unlikely to notice the change unless they use multiple runtimes and Docker is not their default. In that case, `update` may stop updating Docker for them when it would have done so previously. The output of `update` should make this clear though. This change also improves the help, output, and other messaging of `update` to not assume that Docker is the only runner in use. (It predated runners other than Docker in this codebase.) As part of this, the signature of RunnerModule.test_setup() now allows a "not supported" (None) return value, in addition to the existing boolean for success/failure. Resolves <#87>.
tsibley
added a commit
that referenced
this issue
Sep 14, 2022
With no arguments, the default runtime is updated. The name of another runtime to update instead may be provided as an argument. In practice this isn't much of a behaviour change because only one runtime currently supports updating (Docker); the others (native, AWS Batch) just pass. Existing users are unlikely to notice the change unless they use multiple runtimes and Docker is not their default. In that case, `update` may stop updating Docker for them when it would have done so previously. The output of `update` should make this clear though. This change also improves the help, output, and other messaging of `update` to not assume that Docker is the only runner in use. (It predated runners other than Docker in this codebase.) As part of this, the signature of RunnerModule.test_setup() now allows a "not supported" (None) return value, in addition to the existing boolean for success/failure. Resolves <#87>.
tsibley
added a commit
that referenced
this issue
Sep 23, 2022
With no arguments, the default runtime is updated. The name of another runtime to update instead may be provided as an argument. In practice this isn't much of a behaviour change because only one runtime currently supports updating (Docker); the others (native, AWS Batch) just pass. Existing users are unlikely to notice the change unless they use multiple runtimes and Docker is not their default. In that case, `update` may stop updating Docker for them when it would have done so previously. The output of `update` should make this clear though. This change also improves the help, output, and other messaging of `update` to not assume that Docker is the only runner in use. (It predated runners other than Docker in this codebase.) As part of this, the signature of RunnerModule.test_setup() now allows a "not supported" (None) return value, in addition to the existing boolean for success/failure. Resolves <#87>.
tsibley
added a commit
that referenced
this issue
Sep 26, 2022
With no arguments, the default runtime is updated. The name of another runtime to update instead may be provided as an argument. In practice this isn't much of a behaviour change because only one runtime currently supports updating (Docker); the others (native, AWS Batch) just pass. Existing users are unlikely to notice the change unless they use multiple runtimes and Docker is not their default. In that case, `update` may stop updating Docker for them when it would have done so previously. The output of `update` should make this clear though. This change also improves the help, output, and other messaging of `update` to not assume that Docker is the only runner in use. (It predated runners other than Docker in this codebase.) As part of this, the signature of RunnerModule.test_setup() now allows a "not supported" (None) return value, in addition to the existing boolean for success/failure. Resolves <#87>.
tsibley
added a commit
that referenced
this issue
Sep 26, 2022
With no arguments, the default runtime is updated. The name of another runtime to update instead may be provided as an argument. In practice this isn't much of a behaviour change because only one runtime currently supports updating (Docker); the others (native, AWS Batch) just pass. Existing users are unlikely to notice the change unless they use multiple runtimes and Docker is not their default. In that case, `update` may stop updating Docker for them when it would have done so previously. The output of `update` should make this clear though. This change also improves the help, output, and other messaging of `update` to not assume that Docker is the only runner in use. (It predated runners other than Docker in this codebase.) As part of this, the signature of RunnerModule.test_setup() now allows a "not supported" (None) return value, in addition to the existing boolean for success/failure. Resolves <#87>.
Repository owner
moved this from In Review
to Done
in Nextstrain planning (archived)
Oct 6, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
nextstrain updatepredates runners other than Docker and its messaging assumes that Docker is the runner in use. This isn't always the case anymore, and the output ofupdatecan be confusing as it's a mix of messages the CLI prints directly as well as output fromdocker image pull.The
updatecommand could either operate on all supported runners (likenextstrain check-setup) or only operate on the default runner. In either case, runners other than Docker would want to print that they don't currently support updating. (In the future they might.)|| trueand associated todo comment in our CI workflow when this issue is fixed:cli/.github/workflows/ci.yaml
Lines 72 to 74 in 4a95c2b
The text was updated successfully, but these errors were encountered: