Ability to cancel a plan/apply using atlantis cancel

[lkysow]

This feature would enable users to SIGKILL a running apply. This could be added to the apply output page described in #185 or via a comment.

[majormoses]

Ya this is crucial to be able to stop something (such as destroying resources) if an issue was not caught during the plan/review phase.

[bljordan]

On a similar note, it'd be nice to be able to cancel a running plan. For example, sometimes the automatic plan of a large amount of resources kicks off, but we really want to do a plan with a -target flag.

[majormoses]

@bljordan #305 is also related to what your asking for.

[smiller171]

What would happen today if I clicked "discard plan & unlock" in the web UI while running an apply job?

[lkysow]

What would happen today if I clicked "discard plan & unlock" in the web UI while running an apply job?

I'm not 100% sure but I know it wouldn't kill the running tf process. It should fail because there's locks on the directories when they're in use but I haven't tested it.

[tomasbackman]

What would happen today if I clicked "discard plan & unlock" in the web UI while running an apply job?

I'm not 100% sure but I know it wouldn't kill the running tf process. It should fail because there's locks on the directories when they're in use but I haven't tested it.

I just did that.. and it seems like the "unlock" works and the plan is discarded.
But it is not possible to run a new plan due to "workspace currently locked" (by the apply I assume)

[jurgen-weber-deltatre]

yeah, I would not want this. This is dirty, if you come up with something I think a top level config option to decide if it available or not to users is in order.

[leonK-DI]

I think this feature would be awesome... having same issue here

[entscheidungsproblem]

I think this would be a great feature to have! In particular, I was thinking it would be useful to have an option to stop the execution of atlantis apply if any project in an execution group failed.

So, for example, if I had 2 execution groups, each with 2 projects:

• group1 with project1a and project1b
• group2 with project2a and project2b

If project1a or project1b fails on atlantis apply, do not start the execution of the next group, group2.

[nitrocode]

@entscheidungsproblem (and anyone else interested)

Please feel free to propose a PR to address this feature request.

[ValeriiVozniuk]

Still needed feature. Simple use case: you see that apply is hang due to some missing dependency, and just waiting to be timed out. You can abort it, fix the dependency, and restart the process. Currently you need to wait for 20-30-40 minutes for apply to fail when timeouts would be reached.

[nitrocode]

@ValeriiVozniuk thank you for your comment. Please propose a pr and we'd be happy to review it

[entscheidungsproblem]

@nitrocode I might be able to find some time for a PR but would likely need help with reviewing and testing.

I think this function would need an update

atlantis/server/events/project_command_pool_executor.go

Lines 74 to 87 in f8eba4b

	func runProjectCmdsParallelGroups(
	cmds []command.ProjectContext,
	runnerFunc prjCmdRunnerFunc,
	poolSize int,
	) command.Result {
	var results []command.ProjectResult
	groups := splitByExecutionOrderGroup(cmds)
	for _, group := range groups {
	res := runProjectCmdsParallel(group, runnerFunc, poolSize)
	results = append(results, res.ProjectResults...)
	}
	return command.Result{ProjectResults: results}
	}

so the for loop looks like this:

	for _, group := range groups {
		res := runProjectCmdsParallel(group, runnerFunc, poolSize)
		results = append(results, res.ProjectResults...)
+		if res.HasErrors() {
+			break
+		}
	}

But a input flag should also be added to enable/disable this feature

[nitrocode]

That looks promising. Please fork the repo, commit that change to the head branch. Your fork will create a new ghcr image with a dev tag that can then be used as your atlantis. Then you can test this out with your setup and see if your change to catch errors, has the intended effect

Separately but related to this issue, it would be nice to cancel a plan or apply by commenting atlantis cancel or by hitting the api endpoint /api/cancel.

To do that, each time a plan/apply/import/state-rm workflow runs, we would have to save the pid for the job id. Then the cancel command could retrieve the running job id for the pr, get the pid, and then perform a kill on the process, wait until the job is complete, and then finish.

Once we can achieve that, we could also find a way to show running plans/applies in the UI with a cancel button to kill the job gracefully.

[neilscallywag]

Any current workarounds for this ?

[jamengual]

not that I know of

…

On Wed, May 8, 2024 at 7:53 PM Neil ***@***.***> wrote: Any current workarounds for this ? — Reply to this email directly, view it on GitHub <#187 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQ3ERGFLMJMJ3FSX7MPDZLZBLQKBAVCNFSM4FKLXVPKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJQGE4DGOJXHAYQ> . You are receiving this because you commented.Message ID: ***@***.***>

[ishan123456789]

Any current workarounds for this?

Raise another PR from master on no change branch and it should allow to revert the apply