Previously I can cancel testing in list page.
Hi @David - thanks for clarifying & for the description! I'll look into this over the next week and post updates here as I have them.
I'm not Tom, and I think the title of this issue conveys more frustration than a specific issue -- but if I understand @Tim, then I do concur, and may be able to elucidate:
In the old experience it was possible to cancel or restart a job without navigating into its details.
In the new experience, it would save a 5% to 10% of my daily Circle CI interaction time if it were possible to cancel and restart Workflows from the Pipelines list -- specifically, without needing to navigate into the details of each workflow.
A specific use case: my team has triggers / hooks set up to run a Circle CI build for every git push. Normally, this is exactly what we want. However, preparing production releases is different. We follow a modified git-flow methodology, which requires creating a separate release branch and deploy branch after merging a PR branch into the develop branch . This also necessitates back-merging into the master branch . In all, a release typically kicks off 5 concurrent Workflows with essentially identical code content -- where only one of them is needed: the deploy branch
We don't want to disable our automatic build-on-push, and we often have pairs within our team continuing to work on other feature and bug fix branches while one of us prepares the release. However, we only want to pay for the one build during a release - the extra 4 just cost money and clog up our queue of pending builds with redundant work. Being able to cancel 4 of the 5 builds from the Pipelines list would save a lot of irritating navigating around the different Workflows and their details just to cancel them -- and being able to restart a Workflow from the Pipelines list page would also really help when one of us confuses release with deploy (it happens, because in plain English they are similar words, but they mean different specific things for us, it's just that new team members take a bit to learn this distinction) Also -- sometimes when we know we have flaky or unintentionally non-deterministic tests, and there are several feature or bug fix branches which suffer from them before we figure out to stabilize them, it was much more convenient in the old experience to rapidly restart / re-queue 3 to 10 of the failed branches for a repeat test run that might succeed if the flaky-test fairies grant our wishes.
Hi Tom - per our product team's request, can you please provide more information? We'll collect other use cases, feedback and upvotes related to this idea over time for us to take it into consideration.
You won't be notified about changes to this idea.