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.
- 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.
- 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.
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).
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.
kind: secret external_data: docker_username: path: secret/data/docker name: username docker_password: path: secret/data/docker name: password
--- 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