Fix more workflow-state docs. #35
Conversation
| The ID argument can target a workflow, or a cycle point, or a specific | ||
| task, with an optional selector on cycle or task to match task status, | ||
| output trigger (if not a status, or with --trigger) or output message | ||
| (with --message). All matching results will be printed. | ||
| The ID argument can target a workflow, or a cycle point, or a specific task, | ||
| with an optional selector on cycle or task to match final task statuses, | ||
| output trigger (with --triggers), or output message (with --messages). | ||
| You cannot poll for transient states such as "submitted" and "running". | ||
| Poll for the corresponding output triggers instead ("submitted", "started"). |
There was a problem hiding this comment.
Corrections:
- no longer accepts transient statuses, only final statuses
- no longer falls back to trigger if not a known status
--messagewas wrong (it's--messages)
|
|
||
| In "cycle/task:selector" the selector will match task statuses, unless: | ||
| - if it is not a known status, it will match task output triggers |
| - To avoid missing transient states ("submitted", "running") poll for the | ||
| corresponding output trigger instead ("submitted", "started"). |
There was a problem hiding this comment.
This doesn't belong under warnings anymore as we now refuse to poll for transient statuses. I've added the advice on final statuses and triggers to the main text above.
| @@ -370,7 +369,7 @@ def main(parser: COP, options: 'Values', *ids: str) -> None: | |||
| [ | |||
| options.depr_task, | |||
| options.depr_status, | |||
| options.depr_msg, # --message and --trigger | |||
There was a problem hiding this comment.
Comment was wrong and isn't really necessary anyway.
There was never any --trigger option; it is --output and --message (singular) that are deprecated.
| - with --messages, it will only match task output messages. DEPRECATED | ||
| use triggers instead - they match manually and naturally set outputs. |
There was a problem hiding this comment.
Not deprecated though?
| - with --messages, it will only match task output messages. DEPRECATED | |
| use triggers instead - they match manually and naturally set outputs. | |
| - with --messages, it will only match task output messages. It is recommended | |
| to use triggers instead - they match manually and naturally set outputs. |
There was a problem hiding this comment.
It is deprecated, isn't it? We support querying output messages for back-compatibility, but there's no good reason to choose messages over triggers now, so we should eventually drop the option.
There was a problem hiding this comment.
There's no deprecation warning with the --messages option
There was a problem hiding this comment.
Hmm. Maybe it should have one. Not sure if I imagined the deprecation, just thought it should be deprecated, or got the idea from Oliver via his earlier tidy-up PR - ping @oliver-sanders ?
There was a problem hiding this comment.
I think the deprecated applies to querying by task state, not message.
Querying by task state can be flaky, it would be reasonable to deprecate this.
Querying by task message isn't much different to querying by task trigger. It might be useful if the message isn't registered as an output.
Side PR to cylc#6477