Have builds only run when a certain branch is updated

Drone Support
1

Tried when+branch and trigger+branch but anytime anyone makes any change to any branch or a tag a build is triggered.

2

There are no known issues with the when and trigger clauses; these features are considered quite mature. I recommend posting the following information so we can assist you further:

  1. your provider (github, gitlab, etc)
  2. your full yaml configuration file from the commit in question
  3. your build metadata via drone build info <repo> <build>
4

this is missing the results of drone build info <repo> <build> which is required to advise further.

6

We just ran a test from a feature branch:

The branch name was test-ssh-windows and did not match the when clause which was configured to only resolve to true when master. As a result the step was skipped. You can see the results at here

7

thanks for providing the output of drone build info. The branch is evaluated against the target branch for pull requests, not the source branch. Since the target branch is master, we expect your when clause to evaluate to true and execute.

8

Ok so how do I change that behaviour?

I only want to track branch “test” and run a build when there is a push to that branch.

9

I only want to track branch “test” and run a build when there is a push to that branch.

So you do not want to execute the pipeline for pull requests to master? In that case you would do the following:

trigger:
  branch:
  - test
  event:
    exclude:
    - pull_request

The above configuration would result in only pushes to test being executed. It would ignore pull request creation or sync events coming from branch test.

10

Thanks, will give that a try!

11

Does the drone.yml file have to exist in the master branch? Or can it exist in any branch?

We are evaluating drone ci and do not want to add additional files to master and would ideally keep this all contained within the branch labeled ‘test’.

12

Yes the configuration file has to exist in the branch for the commit sha. If you want to override this behavior you can create a configuration extension, which can be used to customize how configuration files are fetched.

13

So currently without bringing in custom extensions to the mix how are multiple environments each tied to their own branch on git handled?

e.g We have 3 environments
test -> dev -> production

Their github repos respectively are
test = test
dev = dev
production = master

It sounds to me like you guys suggest to store everything for every environment/branch within a single drone.yml that is within the master branch on git?

14

If you push to branch master then Drone will fetch your yaml from master. If you push to branch develop then Drone will fetch your yaml from develop. I am happy to advise further but I’m not sure I have enough information to do so at this time.

15

Nope no further explanation is needed, that behavior is sane and was what I was hoping for.

Thanks

16

The trigger section really does not seem to work as intended.

In .drone.yml on branch test it has trigger section like so:

trigger:
  branch:
  - test

But on the drone server builds are triggering when anything is done on github remote even if the action has nothing to do with the branch ‘test’.
e.g People submit a pull request from branch foobar to master and a build starts up.

This behavior doesn’t make sense - If the trigger is set explicitly to branch: test why are all other actions not ignored entirely?

Example of a build triggering which has no relation to branch ‘test’

Number: 256
Status: success
Event: push
Commit: ab0d7302911055eea5695e9bcfccca0356923600
Branch: abzal_brazesubsaving
Ref: refs/heads/abzal_brazesubsaving
Author: mpostman
Message: IFNULL SubscriptionShippingSaving SUM set 0
17

I cannot reproduce any issues with triggers. We are using this feature heavily in production without issue, but for good measure I ran tests to verify.

I pushed a commit to master and updated the configuration:

  commands:
  - hello
  - world

+trigger:
+  branch:
+  - develop

If you look at the build list you will see no build was triggered for this commit sha, demonstrating triggers are working as intended.

With that being said, I would encourage you to explore the underlying code if you feel strongly there is an issue with Drone. Here is a link to the relevant code and unit test:

18

So this yml file is expected to work correctly if I only want builds to trigger from the branch ‘test’?

kind: pipeline
name: foobar
type: ssh

server:
  host:
    from_secret: test-env-vm_host
  user:
    from_secret: test-env-vm_user
  ssh_key:
    from_secret: test-env-vm_key

platform:
  os: linux
  arch: amd64

trigger:
  branch:
  - test

steps:
- name: deploy
  commands:
  - npm install
  - rsync --archive --delete --exclude=config.json . /home/user/foobar/
  - redis-cli flushdb
  - node --max-old-space-size=8192 /home/user/foobar/jobs/foobaz.js run
  - pm2 reload all
  environment:
    HOME: /home/user

Is there something I could be missing?

19

Let’s assume you have this yaml file in branch master and in branch test:

kind: pipeline
name: default

steps:
- name: hello
  image: alpine
  commands:
  - echo hello world

trigger:
  branch:
  - test

and this yaml in branch develop with no triggers section:

kind: pipeline
name: default

steps:
- name: hello
  image: alpine
  commands:
  - echo hello world

Here are a few different scenarios that describe how the system will behave:

  • if you git push code to master
    • github sends a push hook
    • drone fetches the yaml from master
    • the target branch does not match branch test in the trigger section
    • no build is scheduled.
  • if you git push code to test
    • github sends a push hook
    • drone fetches the yaml from test
    • the target branch matches branch test in the trigger section
    • a new build is scheduled
  • if you git push code to develop
    • github sends a push hook
    • drone fetches the yaml from develop
    • there is no trigger section which means the push matches by default
    • a new build is scheduled.
  • if you open a pull request from test to master
    • github sends a pull request hook
    • drone fetches the yaml from the source branch test
    • the target branch is master and does not match branch test in the trigger section
    • no build is scheduled.
  • if you open a pull request from master to test
    • github sends a pull request hook
    • drone fetches the yaml from the target branch master
    • the target branch is test and matches branch test in the trigger section
    • a new build is scheduled.

So this yml file is expected to work correctly if I only want builds to trigger from the branch test?

I do not mean to be difficult but this question leaves some room for interpretation and it would be nice to clarify. Do you mean to say that you only want builds to execute when you git push to branch test? what does the yaml look like in branch test? what does the yaml look like in other branches?

20

Thanks that description helps a lot.

It turns out people had created branches which contained a .drone.yml that was pushed to git without containing a trigger section to limit builds to the select branch.

Those examples you provided are very helpful though, if there are no such examples within the official docs it would be great to add them there.

21

I can see there is a security issue with the way this works.

How would you stop a developer with malicious intent from pushing code to production?

If someone creates a branch and then modifies the .drone.yml they could put the same values for the SSH host/user/key for production servers, set the trigger to their own branch and then push their branch to github.

The drone server would then trigger a build against the values of the SSH host/user/key which would effectively push and override code on any given server.

How do you protect against this?

22

If you do not trust your developers you should take the following steps:

  1. revoke permission to push directly to the repository
  2. require pull requests for all changes to be merged mainline
  3. conduct code reviews
  4. enable protected branches

This will prevent a malicious user from gaining access to a secret, since secrets are not exposed to pull requests by default. It will also prevent users from being able to modify the yaml without that being observed in a code review.