Eric Holmes

Do you think https://github.com/ejholmes/slashdeploy/pull/60 will solve this? When this happens, you'll get a DM from @slashdeploy saying: ``` Hey @turadg. I was going to deploy xxx to production for you,...

Ahhh, I see what you're saying. That's a really good idea, and I think would be relatively straightforward to implement.

One thing that isn't so straightforward with this is that, when you request a deployment through /deploy, you're usually giving a ref (branch/tag, eg. "master") and the GitHub deployments API...

Agree with @sumeet. I think it'd be dangerous to let auto deploys go through, even if you hold the lock. The current behavior [isn't an accident](https://github.com/remind101/slashdeploy/blob/master/spec/features/auto_deploy_spec.rb#L64-L74). With that said, the...

Hey @troyready / @GarisonLotus. This is a slightly more generalized version of what we do internally. Eventually, I'd like to support automating this more in the config, like I talk...

> We already prevent two stacks from being named the same, we could also prevent two stacks from having the same stack_name where if not defined, we assume stack_name =...

@ttaub _probably_ dynamo so it can be shared easily, but could be anything that can implement a `lock()`, `unlock()` interface. Empire has a similar concept to synchronize many concurrent deployments....

I think I would be in favor of the more generic "plugin" system; basically just making `stacker.ui` overridable. I think it'd be hard for stacker to support every CD workflow...

@brettswift something along the lines of this could be cool. I think, at the very least, support for stacker to continue execution if the changeset is _manually_ approved through other...

I think having this be a configurable global default would be nice. At Remind, it’d definitely make sense to make this the default for all of our stacks, just for...