1.0.0-rc.6 release notes


#1

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

Vault: no basic auth credentials with private registry
Kubernetes External Secrets not work
Build task can not reach the agent node in the version of drone/agent:1.0.0-rc.6
Upgrade from 1.0.0-rc.5 to 1.0
#3

I just upgraded to 1.0.0-rc.6.

For future reference, you can easily export the logs from the sqlite database to move them to S3 using: sqlite3 /path/to/drone.db 'select writefile(log_id, log_data) from logs;', and then uploading the resulting files to the bucket.

Also, it would be nice if you could show a message if cron isn’t enabled in the license, as it was a bit confusing when I first installed 1.0.0 and the cron tasks weren’t running.


#4

Cron is enabled by default in the official docker image. You will see the following debug message when the system initializes:

{
  "interval": "30m0s",
  "level": "info",
  "msg": "starting the cron scheduler",
  "time": "2019-03-09T23:50:39-08:00"
}

One thing to note is that the cron processor is not meant to be an accurate scheduler. Using the default configuration, the cron scheduler wakes up every 30 minutes and checks to see if any jobs should have run since the last execution, and then executes them. This means if you schedule a job to run every 15 minutes, they will never execute more frequently than every 30 minutes unless you change the default interval.

Also it is only recommended to set cron values via the user interface, using the @hourly, @daily, @weekly and @monthly dropdown values. If you tried to set the cron value using the command line utility, for example, there is a high probability it will not work as expected because our cron parser expects the seconds field, which is not commonly used and non-obvious. More details here.

Lastly the Cron scheduler has detailed debug logging (sample below) in place for easy troubleshooting if something is not working the way you would expect. Have a look at https://github.com/drone/drone/blob/master/trigger/cron/cron.go

{
  "level": "debug",
  "msg": "cron: begin process pending jobs",
  "time": "2019-03-10T00:03:38-08:00"
}
{
  "level": "debug",
  "msg": "cron: finished processing jobs",
  "time": "2019-03-10T00:03:38-08:00"
}

#6

OK, thanks. It seems that the times in the cron table in the db were completely wrong for some reason (they were way into the future). I set them to 0 and everything worked perfectly.

Also, is there a reason why I now have a _key secret in every repo? I don’t remember adding one.


#7

earlier versions of the release candidate added a secret called _key automatically when the repository was activated. This was removed in rc.5, so these are simply artifacts of a no-longer-used feature and can be removed manually if desired.


#8

As far as drone1 is concerned we never ran anything other than rc5 and now rc6.

We too have these _key entries that I don’t think we had (or saw) in rc5.


#9

We too have these _key entries that I don’t think we had (or saw) in rc5.

you are right, the _key functionality was removed in rc.6 and existed in rc.5. my previous comment is otherwise still accurate.

earlier versions of the release candidate added a secret
called  `_key`  automatically when the repository was activated.
-This was removed in rc.5, so these are simply artifacts of a
+This was removed in rc.6, so these are simply artifacts of a
no-longer-used feature and can be removed manually if desired.

#10

I didn’t mean to offend, my apologies.

For what it’s worth we’re super stoked and happy about drone v1.

The refactor of the job pull codepath made it work 100% flawlessly when hosted in kubernetes with unreliable TCP connections (from external VM’s). So much much kudos from us! <3