rfc: rename deployment event to promote, add rollback event

[bradrydzewski]

The deployment event type seems to be causing some confusion. People read the documentation trying to answer the question "how do I deploy with drone" and they read the section about deployment events, which is generally not what they are looking for.

I think using promotion would reduce terminology confusion and more accurately describes how the system is actually working. We are promoting build X to environment Y ...

- drone promote foo/bar 12 production
+ drone deploy foo/bar 12 production

pipeline:
  deploy:
    ...
    when:
-     event: deployment
+     event: promote

I would also like to introduce a rollback event. This would allow you to explicitly rollback to a previous version. The behavior would be similar to promote, except that you could use the event type in your pipeline to perform a different set of actions ...

drone rollback foo/bar 12 production

IMPORTANT we should be able to implement this without breaking anything. When drone encounters deployment it can automatically convert it to promotion behind the scenes

[gtaylor]

tldr; Instead an additional event type, perhaps we should consider user-specified event types instead.

I've sometimes wished we had a more general way to trigger an arbitrary event type. The deploy event type has always felt like an odd duck to me. In considering additional event types that are arbitrary to some users (ex: we always roll forward, never back), I wonder if we're better off with something more general.

I think being able to trigger pre-defined (by the user) event types, potentially passing params/args would satisfy deploy/rollback and other workloads:

drone trigger <event-type> <repo> <build-id> -p <var>=<val>

Where <event-type> could either be arbitrary, or one of a number of pre-configured (by env var) event types.

For example, mimicking our current deploy event:

drone trigger deploy foo/bar 12 -p TARGET=production -p DIRECTION=forward
drone trigger deploy foo/bar 12 -p TARGET=production -p DIRECTION=back

Or if the user wanted to go a slightly different route:

drone trigger deploy foo/bar 12 -p TARGET=production
drone trigger rollback foo/bar 12 -p TARGET=production

Or maybe I want to do something weird like

drone trigger only-deploy-s3-assets foo/bar 12

I could have my s3 publishing step's when selector be something like [deploy, only-deploy-s3-assets], easily allowing partial deploy/publication without plugin modification.

[bradrydzewski]

and just to support my claim above that deployment event types are causing confusion. From the gitter room today:

I have a question about deployments. I am reading the doco ( http://docs.drone.io/deployments/) and from my understanding the only way to trigger deployment to dev/staging/prodction is to use command line "drone deploy ”. Could you please confirm/clarify if there is another way? Can deployment triggered automaticly based on certain conditions?

[bradrydzewski]

@gtaylor yes I agree. It is something we need to unwind carefully since there are security implications with regard to secrets being exposed. But agree that we seem to be moving in this direction anyways, and might as well just embrace it.

[one000mph]

I'm going through an upgrade from 0.8 to 1.2 and have a couple questions related to this issue. Hope it's OK that I'm commenting here even though it's closed.

1. It appears that the event name deployment is no longer valid based on the behavior I see. Was this supposed to be backwards compatible? I am not able to run steps that were working in 0.8 with the deployment event trigger.

2. Is there a way to make the webhook listen for deployment events by default? In 0.8 there I had to check the box in repo settings, but the UI and CLI don't seem to support this. My current workaround is to enable is on the webhook settings in github, but that seems a bit fragile if I need to recreate this webhook later.

[bradrydzewski]

Is there a way to make the webhook listen for deployment events by default? In 0.8 there I had to check the box in repo settings, but the UI and CLI don't seem to support this. My current workaround is to enable is on the webhook settings in github, but that seems a bit fragile if I need to recreate this webhook later.

this was fixed in master and in the :latest docker image.

It appears that the event name deployment is no longer valid based on the behavior I see. Was this supposed to be backwards compatible? I am not able to run steps that were working in 0.8 with the deployment event trigger.

the event was renamed to promote because it more accurately described how most people were using deployments with Drone.