Drone 2.0 Brainstorm

Development
1

Just a reminder that this thread is to propose breaking changes that we cannot make in the 1.x release cycle. It is not a generic feature wishlist :slight_smile:

This is a running list of changes I want to see in a Drone 2.0 release. These are breaking changes that we cannot otherwise include in 1.x releases. I want to be clear that there are no immediate plans for a 2.0 release and for the next year we plan to focus on 1.x only.

1. Environment Substitution

Emulating bash substitution for ${variable} syntax and escaping variables with $${variable} syntax is probably one of my biggest regrets. This behavior is non-obvious and causes a lot of confusion for newcomers.

In Drone 2.0 I would like to change the syntax to ignore ${variable} and to only substitute variables with $${variable} syntax. This means $$ syntax will cause substitution as opposed to prevent substitution.

We can probably make this a feature toggle so that existing installations can upgrade to 2.0 but revert back to 1.x behavior.

2. Strict Yaml Validation

Enable strict yaml parsing. This means parsing will fail when the yaml contains unknown keys or structures. This will make it easier for teams to catch errors.

This has breaking implications for teams declaring anchors, since these tend to be freeform fields and would fail validation. Atlassian solves this issue by requiring all anchors be defined under a definitions section of the yaml.

definitions: 
  steps:
    - step: &build-test
        name: Build and test
        script:
          - mvn package
        artifacts:
          - target/**

pipelines:
  branches:
    develop:
      - step: *build-test
    master:
      - step: *build-test

We can probably make this a feature toggle so that existing installations can upgrade to 2.0 but revert back to 1.x behavior.

2

HA for Drone? :slight_smile:

I realised that the session is stored locally so running multiple Drone instances I had to use sticky sessions at the load balancer.

Also log shipping was acting weird, since some stages showed the logs only after the stage has completed.

I am not sure how much Drone is prepared to function in a stateless manner, enabling us to run multiple instances for HA, but it would be a huge step forward for bigger installations.

3

HA is planned for the 1.x release cycle and is something we have been working toward (2.0 is more about breaking changes that we cannot introduce in the 1.x release cycle).

Also log shipping was acting weird, since some stages showed the logs only after the stage has completed.

I am not sure how much Drone is prepared to function in a stateless manner, enabling us to run multiple instances for HA, but it would be a huge step forward for bigger installations.

I provide an overview of current design, limitations, and rationale here:

1 Like
4

3. Runner not triggered

5

Hi, it would be great if such opportunities were available in the drone

  • Ability to configure pipelines in multiple .drone.yml files.
    IMHO, this will greatly simplify the pipeline settings for mono repositories
  • skip a step, but continue to perform other steps in the pipeline
  • start the last successful build of the specified branch via API (without explicitly specifying the build number)
  • add a trigger on branch removal
1 Like