Roadmap for the 1.0 release

Drone Support
1

Quick overview of major features planned for the 1.0 release this summer. The 1.0 release will include a compatibility promise as we shift focus from feature development to stability.

Matrix Syntax Deprecation

The matrix syntax is a legacy feature that we adopted from Travis. Our matrix implementation is rather limited and does not support the following critical use cases:

I want to send an slack notification after all matrix steps complete

I want to execute my deployment after all matrix steps successfully complete

The .drone.yaml file will support complex pipeline workflows, including fan-in and fan-out, providing a powerful alternative to the legacy matrix feature.

GRPC Fallback

Support http1 / REST fallback for environments where grpc is not well supported or where grpc connections are being killed or timing out.

Agent Routing

Agents currently poll a single queue for builds. This makes it difficult for agents to filter which types of builds it will execute. Example use cases:

  • Agent should only handle builds that need GPU access
  • Agent should only handle builds with low-CPU or low-memory requirements
  • Agent should only handle builds with high-CPU or high-memory requirements
  • Agent should only execute builds for production deploys
  • Agent should only build pull requests
  • Agent should only execute builds for the linux {arm,arm64,arm32} architecture

We will implement a mechanism for tagging builds and routing builds to specific groups of agents based on the tag value.

Triggers

Repository settings such as trusted mode or the path of the yaml configuration file are currently stored at the repository level, which means they apply to every build for that repository. We will provide a mechanism to customize the configuration at a more granular level, taking branch, event and platform into consideration.

We hope to support the following use cases:

  • Use a different yaml based on branch
  • Use a different yaml based on push vs pull requests vs deploys
  • Use a different yaml based on platform (eg linux/amd64 vs linux/arm vs window/amd64)
  • Use a different yaml based on subdirectory (monorepo)
  • Enable trusted mode based on branch
  • Enable trusted mode for push events only, disable for pull request events

This will likely manifest itself into a new feature called triggers. When you activate a repository, you will configure one or more triggers that define if and how a build should be executed. Here is a high-level overview of how I expect triggers to work:

  • a repository can have one or many triggers
  • each trigger will define the location of the yaml file, target platform, trusted flag
  • each trigger will define matching logic based on branch, event, author, etc
  • a hook from github can match zero or many triggers
  • when a hook matches a trigger, a build is launched with the trigger settings (yaml path, trusted flag, platform, etc)
  • if a hook matches multiple triggers, it will trigger multiple builds.

This will also tie into agent routing (mentioned previously). When you create a trigger you will be able to configure the agent tag so that it can be routed appropriately.

Queue Improvements

Continue to improve the queue, including the ability to gracefully recover and restart jobs when an agent loses connectivity.

9 Likes