Using "Drone Conditions" for running builds part of a repository

Question

Our project is nested inside a mono-repository. Imagine this, we have a project in a "projects" folder. For example "projects/our-project". Well, we would like to be able to check our .drone.yml into just "our-project" but it appears Drone wants the configuration file at the root of the project, which is ok, we can work with that by changing the "commands" section of our builds. The trouble we are running into is that we only want to run the builds when something in "our-project" changes. I can't find a way to do that precisely with Drone so our next closest bet is conditions, I figure we can make namespace all branches for "our-project" like this "our-project/some-branch". Then we could set up a condition, to only run builds on "our-project/some-branch" and "master" this would limit the number of "fake builds" we are running from other projects branches:

build:
  when:
    branch:
      - master
      - our-project/*

The trouble is when we try to pull request from a "our-project/" branch to "master" the build won't run, I'm guessing because its being run on a merge commit which isn't in master or "our-project/"

My question is two fold: 1. What is the best way to leverage drone using the mono repository pattern (multiple projects, one repository) 2. If Drone doesn't have support for that pattern or isn't designed for it, what is the best work-around to limit "fake builds"

Note: We could at the beginning of our build check for changes in our sub-folder and return a green if there aren't any. I this a recommended approach?

Answer 1

There's multiple solutions for this problem now.

As a start you can use exit (78) code which skips subsequent steps in pipeline but this workaround require you to define multiple pipelines that can be skipped.

Example:

- name: Check_src_for_changes
  image: alpine/git
  commands:
  - if (git diff --exit-code $DRONE_COMMIT_BEFORE $DRONE_COMMIT_AFTER -- src); then exit 78; fi

Also This is currently handled multiple extensions due to the new category of Drone plugin called a configuration plugin:

• docs.drone.io/extensions/conversion
• docs.drone.io/extensions/configuration

Anyone can create an extensions using drone starter projects

• drone/boilr-convert
• drone/boilr-config

Extensions can be used to override how Drone fetches a yaml allowing you to create or modify yaml files on the fly. There are multiple extensions that solve this problem today that you can use. Here are a few:

• meltwater/drone-convert-pathschanged
• bitsbeats/drone-tree-config
• microadam/drone-config-changeset-conditional

For more about this issue please refer to issue#1021

Answer 2

I think this should be somewhat better in Drone 1.x due to:

Triggers

Triggers will fix the fake builds problem as drone won't start the build if it doesn't satisfy the trigger condition.

Muti Machine Builds

Multiple pipelines are now supported in one drone file. eg:

kind: pipeline
name: frontend

steps:
- name: build
  image: node
  commands:
  - npm install
  - npm test

---
kind: pipeline
name: backend

steps:
- name: build
  image: golang
  commands:
  - go build
  - go test

You can have different triggers for each.

Also drone files can be specified in directories other than the root directory now throught the drone cli:

drone repo set octocat/hello-world config.path .github/.drone.yml

Source : https://github.com/drone/drone/issues/1965.

For the problem of pull requests having the base branch be master, that I don't think can be fixed. The workarounds I can think of are:

Mark repo as protected

This will only allow Pull Request builds, and branch builds even, when approved by a member through the drone cli or UI. So you can set up some other webhook receiver for PR pushes that automatically approves the corresponding builds on drone for those branches and disapproves for other branches.

Promotions

Make a dummy pipeline with a single step that only triggers on pull request.

And after it is completed, use a webhook or even a step in this dummy pipeline itself, to promote this build to some specific target(environment) through the drone API if it is for a branch of our_project and have another pipeline trigger on that target.

Answer 3

I guess that Drone enforces a specific project layout because one constraint:

• Drone is triggered by the following events: push, pull request, tag, deployment. All triggers are repository level events.

The following two constraints are also important but not determinant in this case:

• One repository, one .drone.yml, one pipeline
• .drone.yml must be in the project root

If you have one repository containing multiple projects, no matter the structure, you cannot trigger the build pipeline based on specific assets being updated.

If you have big multi-module projects and you don't want to build the whole project on each push, the best thing to do is to refactor the project placing each module in their own repository and configuring Drone pipelines to trigger downstream/upstream builds on dependencies/dependants as needed.