In Drone 0.4, there were specific steps in the pipeline. Build, publish, deploy. In the event that someone forks your repo and submits the code back in an MR, the deploy step was not executed.
In Drone 0.8 due to the change to a pipeline, all steps are executed regardless. If someone is to commit onto the master branch of a fork of your code and submit it, the deployment step is executed - meaning code will end up in production without it actually stopping to be merged in.
In some instances, the YAML for Drone can be modified in an MR and executed - meaning that even if you do have a step with a limitation on branch, that YAML will still be read by drone and executed.
Has anyone any ideas how we can prevent certain steps from being executed in Drone during a fork and merge like we could in 0.4?
@jhernandez mentions you will want to use conditions. Also note that by default secrets are not exposed to pull requests. So even if the deployment step were executed, the secrets would not be exposed, and the deployment would presumably fail without credentials.
Yep, but that’s provided that the steps use secrets.
Just to be clear - if you have a fork where the work is done on the master branch and you submit a merge request, Drone will evaluate the branch to be master. The conditional also has to be excluding pull requests.
This is also all under the assumption that the drone.yml is not modified in the merge request to remove the conditionals of course…
I don’t follow but you can limit your step to execute only in certain events for example
when:
branch: master
event: push
Pull requests are sent with event as pull_request, so won’t be executed with pull requests coming from a fork and if they try to change this restrictions you still have gated builds see this
Correct, if you look at the .drone.yml for drone, you will see a number of blocks that look like this (below) to restrict when steps are executed:
when:
branch: master
event: push
Yes. If you have the ability to execute a deployment without secrets, a user could accidentally remove the conditionals from the yaml and thus execute a deployment when they shouldn’t.
You have options to handle this. One option, assuming you are using a custom plugin for deployments, you could instruct the plugin to ignore pull request events. If the user omits conditionals, and the event type is a pull request, the plugin will execute but will not take any action.
A second option would be to use the protected build feature to block and require manual approval if a pull request from a non-administrative user alters the yaml configuration. I don’t recommend protected builds unless absolutely necessary, though. They are a bit heavy handed and we’ll likely come up with something better before a 1.0 is launched. With that being said, I use them in some cases, where I need to expose a secret (typically slack token) to a pull request for notification purposes and I therefore need to lock down the yaml.
