Drone 0.5 is sometimes too fast for GitHub


Occasionally, I’ve noticed tests on our Drone 0.5 (latest 0.5 tag on Dockerhub) sometimes start too quickly and beat GitHub to the punch. On push events, this manifests as a simple test failure, where you can simply restart the build and it’s fine.

But on PRs it does something much more insidious: it silently builds the wrong revision, because it never explicitly checks out the revision in the event.

I’m thinking two things really ought to be considered here:

  • Should/can the sequence of Git commands be augmented to be more specific? I am not sure if it is possible, but it would at least be nice see what the commit hash actually is and checking it against the event.
  • If it does fail, should it retry a few times before failing?

P.S.: I am not sure if Drone 0.5 is the correct version to be using. I am mostly OK with breaking changes, but the way versioning is handled here is perplexing to say the least. The tag for 0.5 we were using for many months randomly became something entirely different! I am sure this is already discussed elsewhere, but if I need to be using a different version let me know. This is a production setup.

see https://github.com/drone/drone/issues/1000
and https://github.com/drone-plugins/drone-git/pull/38

There is a pull request to checkout the pull request by sha. Unfortunately it cannot be merged because it isn’t passing unit tests. But we certainly would accept a pull request to improve this behavior.

The tag for 0.5 we were using for many months randomly became something entirely different

Docker tags are not immutable and may change. Some teams treat them as immutable version numbers, and others do not. The golang:1 tag, for example, points to the latest 1.N release. This means docker pull golang:1 could return a different version of Go depending on when you pull the image, and what the latest Go version is at that time.

The drone:0.5 tag points to the latest 0.5.N release, which points to the latest 0.5.N+BUILD release. The 0.5.N+BUILD is unique and immutable.

OK, I suppose that answers most of my questions. Thanks.