Merge pull request #732 from oliver-sanders/set-outputs

change set-outputs -> set

src/7-to-8/major-changes/cli.rst

@@ -80,16 +80,16 @@ renamed or removed.
 ``cylc print``
   - Equivalent to ``cylc scan --states=all``.
 ``cylc reset``
-  - It is no longer possible to manually change a task's state.
-  - You can, however, override the outputs the task generated which has a
-    similar effect with ``cylc set-outputs``.
+  - ``cylc reset`` has been replaced by ``cylc set``
+  - At Cylc 8 we override task's prerequisites & outputs rather than modifying
+    the task state directly.
 ``cylc restart``
   - Replaced by ``cylc play``.
 ``cylc run``
   - Replaced by ``cylc play``.
 ``cylc spawn``
   - Spawning is now performed automatically, on demand. Use ``cylc trigger`` to run
-    a task, or ``cylc set-outputs`` to spawn tasks that depend on specified outputs.
+    a task, or ``cylc set`` to spawn tasks that depend on specified outputs.
 ``cylc suite-state``
   - Renamed as ``cylc workflow-state``.
 

src/user-guide/running-workflows/handling-job-preemption.rst

@@ -17,10 +17,4 @@ because Loadleveler sends the SIGUSR1 signal before SIGKILL for preemption.
 Other :term:`job runners <job runner>` just send SIGTERM before SIGKILL as normal, so Cylc
 cannot distinguish a preemption job kill from a normal job kill. After this the
 job will poll as failed (correctly, because it was killed, and the job status
-file records that). To handle this kind of preemption automatically you could
-use a task failed or retry event handler that queries the job runner queue
-(after an appropriate delay if necessary) and then, if the job has been
-requeued, uses ``cylc reset`` to reset the task to the submitted state.
-
-
-
+file records that).

src/user-guide/running-workflows/retrying-tasks.rst

@@ -45,6 +45,6 @@ sequence, or remove it.
 
 
 If you want trigger downstream tasks despite ``3/foo`` being removed before it
-could succeed, use ``cylc set-outputs`` to artificially mark its ``succeeded``
+could succeed, use ``cylc set`` to artificially mark its ``succeeded``
 output as complete (and with the ``--flow`` option, to make the :term:`flow`
 continue on from there).