Info: DroneCI v0.3

[arm4b]

Comparing to v0.4, Drone v0.3 doesn't support build matrix.

0.4 stable is just released yesterday and drone/drone master just migrated to the new codebase, meaning v0.3 is considered unsupported/outdated from now.

Sadly we can't use 0.4 because of issues described #9. However there were some crazy ideas to make v0.3 working.

So the idea is: Instead of relying on v0.4 matrix, we can just run needed number of DroneCI instances simultaneously and connect them with our GitHub repo, so they would run in parallel. Golang hacks armab/drone#1 and armab/drone#2 made it possible (TBH this is my first Golang touch). So I built it from sources and ran 3 different drone instances with 3 different configs.

Worked surprisingly well on one AWS server and looks nice:

Now we have 3 configs for every build instead of one .drone.yml:

• .drone.debian.yml
• .drone.ubuntu.yml
• .drone.centos7.yml
• Example Pull Request with status

  Pros

• self-hosted CI, - this is really cool and brings full control
• we can add custom logic by editing sources (limited to Golang skills)
• show different statuses in Pull Requests for every distro. This is rocking hack, which is not possible with any 3rd party CI. I especially like it, because it gives status about every distro ASAP (the screenshot demonstrates it well).

  Cons

• v0.3 is outdated, meaning it will become more and more obsolete and unsupported with time
• there is no option to run deploy section when all builds were successfull, as we have in CircleCI #6. We need something like this to upload artifacts only when everything went well
• linked services have no additional settings: no shared volumes, no custom ports or commands
• because of ^^ there are differencies in running docker-compose and drone. I would prefer ability to 100% reproduce local and CI builds. For example there are small (solvable) problems running centos7 and debian builds.
• no good API and documentation

  References

• Drone v0.3 docs
• Forked Drone 0.3 version with small edits

  Conclusion

With possibility to run builds in parallel and even with limitations described, Drone v0.3 looks like one of possible solutions, same as CircleCI, both with its unique features.

• Drone v0.3
  • self-hosted CI, OpenSource, we can change it (Golang), but very minimal in features
  • parallel builds with hack, custom Github PR status for every build in matrix
  • fast if we host it on good server
  • no bult-in docker-compose, because of drone configs, meaning no reproduceable local and CI builds
  • needs some fixes, needs setup and maintenance
• CircleCI
  • 3rd-party CI service, no way to change it, but very flexible with tonns of features
  • built-in parallel builds
  • fast, 32CPUs for every build machine and a lot of memory. 4 free parallel slots (VMs) for OSS
  • docker-compose support, meaning 100% reproduce local and CI builds, ssh debug mode
  • good API, ability to trigger builds with custom parameters
  • works well with almost no efforts, saves time.

[dennybaa]

All true, yeah more reasonable approach will be to use CircleCI and wait for drone 0.4.1 with parallelism and fixes.

there is no option to run deploy section when all builds were successfull, as we have in CircleCI #6. We need something like this to upload artifacts only when everything went well

that's quite not true I think, we need publish into bintray and as far as I see there's such possibility https://github.com/drone/drone/tree/v0.3.1/plugin/publish

[arm4b]

Here is what I mean:

Example:

ubuntu build - OK debian build - FAIL centos7 build - FAIL

We shouldn't upload artifacts to bintray, because not all tasks were successful.

ubuntu build - OK debian build - OK centos7 build - OK

All parallel tasks succeeded - we should upload to bintray.

---

We can't do ^^ that logic with Drone, to deploy only when all tasks succeeded. Deploy section will be executed in every sub-task, no way to check other tasks status.

In CircleCI we can do that - upload only when all tasks succeeded.

[dennybaa]

got it. right.

[dennybaa]

closing. We don't favor drone for this task.