Today, in a release when there arises a need to retrigger a COMPLETED task we use RESTART phase button and choose the specific phase where the task lies and then the specific task itself. It works like a charm.
What we would like to also see, is the possibility of retriggering a task that lies within a Sequential Group.
Use case: As an example, our sequential groups has below tasks.
task 1. Fetching versions of services via API calls using webhook
task 2: Jython script to parse through the data and create a key-value map of service and versions
task 3: User input task for the executioner to validate the list of services
task 4: Parallel group which triggers multiple deployments.
If there is a need to start the deployment group from task 3, the only possibility is to select the sequential task group from the dropdown, click on RESUME LATER, manually skip the tasks that do no need re-execution and then click RESUME RELEASE.
It would be better for the users, to find the tasks within the SEQUENTIAL GROUP and choose which task should be the starting point of a restart function.
by: Sanjay M. | about a month ago | Templates & Releases
Comments
Thank you for the suggestion. We plan to explore this idea further and will follow up with some scenarios in this thread.
For the given scenario:
---
Phase
Task1
SequentialGroup1 task
-- Task11
-- Task12
-- SequentialGroup2 task
----Task21
----Task22
----ParallelGroup1 task
Task2
---
When restarting from a task inside a sequential group, what kind of scenarios are you currently dealing with?
- Are the tasks you want to restart from always part of a top-level sequential group within the phase - for example, Task11 and Task12 inside SequentialGroup1?
- Or can the restart point also be within a nested sequential group - for instance, Task21 inside SequentialGroup2, which itself is nested within SequentialGroup1?
- Are there any other combinations we should consider, such as tasks inside parallel groups or deeper levels of nesting?
As of now, for us the possibility of restarting from task12 and skipping task11 is what we are looking for.
Also, below is other scenario.
Parallel group1 task
-sequential group11 task
--task111
--task112
-sequential group12 task
--task121
--task 122
In this scenario, we should have the possibility of restarting a from task 122 or task 112.
This is a very rare scenario that we have seen, but it is still a possibility.
Thank you for sharing the additional scenario involving the parallel group task.
We’ve been considering several similar cases. In the scenario shown in your image - where task 21 is completed and task 22 has failed - restarting first ailed task 2 raises questions about how to handle:
- the completed task 21: should it be skipped or executed again?
- likewise, should task 22 be restarted automatically, or require manual intervention?
This kind of partial re-execution can be problematic, especially when tasks have dependencies or produce side effects. To ensure consistent and predictable behavior, we’ve chosen the safer approach of disallowing restarts from within inner parallel group tasks and requiring a restart of the entire parallel group instead.
That said, we’d really value your input - do you see a way to safely handle this scenario while still allowing more granular control?
If the user has chosen to re start from task22 from SG2, then everything above it should be skipped.
Today, platform asks the user, should the release RESUME NOW or release should RESUME LATER.
This should still be asked when performing RESTART PHASE.