Trigger pipeline defined in Master for other branches


I’d like to define my drone pipeline only in the .drone.yml of the master branch (or default branch of the git repo), and when something is pushed to any branch of the repo (a branch that may not contain the .drone.yml file) it will always trigger the pipeline defined in the master branch.

Is that feasible?

Thank you very much for you help!

Hello there,

to give more precisions, here is my use case: I have a github public repo with a big number of branches (no code similitude between these branches).

I receive many pull requests on these many branches, and a change in the .drone.yml in one of those PR could very well go unnoticed.

The problem is that the last step of the .drone.yml pipeline is a deployment step, that SSH into a prod server to run a service.

A PR could modify the deployment step and if inadvertently merged, do bad things…

That’s why I’d like to have only one version of the .drone.yml file (in the master branch for example).

Is that possible ? Or do you see any other way to let public user merged PR trigger a server deployment step in a secure manner ?

Many thank for your insights!

You can set your repo as Protected in the Repo Settings

This enables gated builds, which will prevent .drone.yml modifications from PRs until you approve those changes.

Which looks like this

1 Like

@jhernandez provides the correct answer - gating would block the build if an unauthorized user modifies your yaml configuration file. You would be able to review and either reject or approve the change to proceed with the build.

I also assume that you have the default secret settings in place, which prevent secrets from being exposed to pull requests. This is documented here

The problem is that the last step of the .drone.yml pipeline is a deployment step, that SSH into a prod server to run a service.

I would like to point out that every file in your repository (not just the .drone.yml) can be used as an attack vector. If you are not closely reviewing pull requests, someone could send a pull request that modifies the .drone.yml or any other source code file in your repository resulting in malicious code being deployed to your servers.

In fact, this attack vector does not even require a CI server. The minute you begin accepting public pull requests, even with manual deployments and no CI, you are subject to accidentally merging a malicious pull request and deploying that code to your servers. Hopefully that risk is very low, but it is there regardless.

1 Like

Many thanks both of you for your very helpful answers. I didn’t know about gated builds! That’s awsome :muscle::+1::heart: