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.