warning: please read carefully before upgrading
The final release candidate, 1.0.0-rc.6 is tagged. This release contains some minor breaking changes to the yaml file and server configuration (read below). This release primarily focused on cleaning up the codebase and finalizing the yaml syntax for 1.0.
When will 1.0.0-final be released? I expect rc.6 with be the final release candidate. I plan to wait approximately 10 days after the release of rc.6 to gather feedback prior to creating the 1.0-final release. During this period the codebase will be frozen, with the exception of bug fixes (no new features, sorry folks). During this time I will be focusing on documentation and the 0.8 database migration utility.
Issues Resolved
- Detect write access to a repository for Bitbucket Stash driver. See #15.
- GitLab status fails to post. See #14.
- GitLab returns partial yaml with lines cut-off. See #12.
- User interface sorts repositories on the dashboard screen by last build date. See #259.
Features Added
- Ability to exit a pipeline early without error. See #51.
- Support for Nomad as the scheduler. See Drone and the Nomad Scheduler.
- Set S3 endpoint for log storage (Digital Ocean, etc). See #2602.
- Set S3 path style for log storage in Minio. See #2602.
Known Issues
Below are known issues that we do not plan to fix prior to 1.0. The native Kubernetes runtime is considered experimental and will remain experimental for the next few months, maybe longer. There are also some minor issues in the user-interface that we will continue to patch after 1.0 is released.
- Support for Kubernetes persistent volume claims. See #19.
- Support for default Kubernetes Resource Limits. See #44.
- Real-time updates in the user-interface do not always work (needs issue).
Breaking Changes
Agent Configuration
If you are using Drone with agents you need to pass DRONE_AGENTS_ENABLED=true to the server. Drone 1.0 provides a single-machine installation that does not require agents and runs the build on the same machine as the server. Many people were accidentally using single-machine mode and then wondering why they could not hook up agents. This configuration makes things more explicit and should help improve the installation process.
External Secret Configuration
The syntax for defining external secrets sourced from plugins (vault, etc) has slightly changed. Our goal is to follow kubernetes conventions when possible, and one convention is that each resource requires a name. This final adjustment to the syntax was done for this purpose.
Before
kind: secret
external_data:
docker_username:
path: secret/data/docker
name: username
docker_password:
path: secret/data/docker
name: password
After
---
kind: secret
name: docker_username
get:
path: secret/data/username
name: username
---
kind: secret
name: docker_password
get:
path: secret/data/docker
name: password
Registry Credentials from Secrets (in the Database)
Previous release candidates used magic keywords to determine if a secret should be used to download private Docker images. Drone now follows Kubernetes conventions and requires you to explicitly define which secrets should be used to pull Docker images, using the image_pull_secrets parameter. Simply add a docker/config.json secret to your repository in the settings screen, and then reference the secret in the yaml as displayed below.
kind: pipeline
name: default
steps:
- name: test
image: octocat/private-image
commands:
- echo hello-world
image_pull_secrets:
- dockerhub
Registry Credentials from Secret Plugins (e.g. Vault)
It is also possible to source your registry credentials from an external secret provider like vault, assuming you have properly setup a secret plugin. You can define image_pull_secrets that reference remote secrets defined in the yaml. See the below example:
kind: pipeline
name: default
steps:
- name: test
image: octocat/private-image
commands:
- echo hello-world
image_pull_secrets:
- dockerhub
---
kind: secret
name: dockerhub
get:
path: secret/data/docker
name: config.json