To sum it up, would it be ok to remove Line 500 here and allow the drone deploy
CLI to deploy a still running build?
Let me explain my use case:
I’d like to start using the “deployment” event so developers have a simple way for triggering a deployment manually. So far so good. But, in some cases, I’d like for the deployment to happen automatically.
Also I’d like to use the deployment API so I have access to the $DRONE_DEPLOY_TO variable, and can configure my deployments dynamically. That’s really important because I have some pipelines which deploy multiple applications to multiple environments, and without an “environment” variable I need to configure Nenvironmnets X Napplications
deployment steps.
One solution I’ve come up with is to trigger a deployment event as part of the pipeline:
# just an example, didn't test it out with the drone/cli image specifically
trigger:
image: drone/cli
commands:
- drone deploy fbcbarbosa/myrepo $DRONE_BUILD_NUMBER staging
environment:
- DRONE_SERVER=foo
- DRONE_TOKEN=bar
when:
event: push
branch: master
# plugin to deploy on a DCOS cluster
deploy:
image: 'quintoandar/drone-marathon'
server: 'http://my-dcos-cluster.$DRONE_DEPLOY_TO.quintoandar.com.br'
marathonfile: $DRONE_DEPLOY_TO/marathon.yml
when:
event: deployment
However, I’m getting this error:
client error 500: cannot restart a build with status running
If I use “last” instead of $DRONE_BUILD_NUMBER, I’d get the previous build, which is not really what I’m aiming for here.
I assume the same could be achieved if we had a more advanced conditional logic (e.g. replay this deploy step with this particular set of environment variables), but given the current Drone capabilities this seems like the best option.