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:
drone build info <repo> <build>
this is missing the results of drone build info <repo> <build> which is required to advise further.
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
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.
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.
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.
Thanks, will give that a try!
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’.
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.
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?
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.
Nope no further explanation is needed, that behavior is sane and was what I was hoping for.
Thanks
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
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:
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?
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:
git push code to master
test in the trigger sectiongit push code to test
test in the trigger sectiongit push code to develop
test to master
test
master and does not match branch test in the trigger sectionmaster to test
master
test and matches branch test in the trigger sectionSo 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?
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.
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?
If you do not trust your developers you should take the following steps:
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.
So that said the only way to secure drone CI is to completely restrict access to master branch including read permissions and/or restrict branch pushing to github entirely.