search

boostorg / core

Boost Core Utilities
133 stars 83 forks source link

Drone config #84

Closed sdarwin closed 3 years ago

sdarwin commented 3 years ago

Drone is a continuous integration framework similar to Travis CI. The C++ Alliance is offering a hosted Drone server for Boost libraries. Please refer to https://github.com/CPPAlliance/drone-ci for more information and instructions.

Lastique commented 3 years ago

How is it different from Travis CI/AppVeyor CI and why do we need another CI? In other words, what does it provide that we currently lack?

sdarwin commented 3 years ago

@Lastique , travis seems to be in the process of switching to a different pricing model, requiring credits. Reports about this vary.

Lastique commented 3 years ago

I haven't heard of this. This needs to be confirmed first, IMHO. Especially, whether there will still be a free plan for open source projects.

Regarding the PR, I don't quite understand why there are similar files with hex strings as names in the PR. Are these necessary? What do these hex ids signify? Also, what does DRONE_JOB_UUID mean and where does one get one?

pdimov commented 3 years ago

This looks like automatically generated from .travis.yml by a script. The hex named scripts correspond to the local script: sections such as https://github.com/boostorg/core/blob/16e9536146e2414a787a077cf15b6bedcde25a22/.travis.yml#L361-L370 and https://github.com/boostorg/core/blob/16e9536146e2414a787a077cf15b6bedcde25a22/.travis.yml#L374-L381.

Yes, travis-ci.org is supposed to be shutting down, and the free plan for travis-ci.com is quite restricted, although the Travis people probably don't themselves know what the exact plans for that are. In either case, it's severely throttled at the moment.

pdimov commented 3 years ago

travis-ci.org says

Please be aware travis-ci.org will be shutting down in several weeks, with all accounts migrating to travis-ci.com. Please stay tuned here for more information.
Lastique commented 3 years ago

This looks like automatically generated from .travis.yml by a script.

Umm, well, we're supposed to maintain it, right? Therefore some cleaning up after auto-generation is in order.

Also, I couldn't find any documentation for these config files yet. .drone.star doesn't look like anything I see on https://docs.drone.io/.

Yes, the transition to travis-ci.com has been going for quite some time, but I was under the impression that it won't affect the existing projects.

sdarwin commented 3 years ago

@pdimov, right.

@Lastique, great questions. I've updated the README file.

"What does DRONE_JOB_UUID mean and where does one get one?"

It doesn't mean anything, but should be unique. They were initially generated by taking a SHA1 hash of the "job number", such as "1" or "2". You could literally use "1" or "2" if you preferred. The point is to have an identifier to distinguish the job so that in the other drone scripts you could conditionally run a step for only one of the jobs if the UUID matches.

"What are the files with the funny hex numbers?"

These drone files were generated with an automated script based on travis.yml. The most common job configuration was detected and called "boost.sh". It's often the main script. For other configurations, if the "install" and "script" portions of the job varied, then they were named based on their sha1 hash value, such as .drone/840114c2a5-fda7c76df5.sh, with .drone.star using the "buildtype" field to reference it. You may optionally change these names to something more meaningful than a hash.

pdimov commented 3 years ago

FWIW, I'm gradually adding Github Actions support to my repos (Core also has one because I needed responsive CI in order to test some ongoing work here and Travis lags for weeks) and once I'm happy with it, I was planning on simplifying .travis.yml by removing all the redundant configs from it (but adding some that are currently missing such as amd/s390x/freebsd) to increase turnaround there.

At the moment GHA works quite well - e.g. https://github.com/boostorg/core/actions/runs/451245853 - so I'm not sure what using Drone would add to it (even though I appreciate the work).

badair commented 3 years ago

Thanks @sdarwin for the PRs on all these libraries.

Travis has been going downhill for years. The recent announcement was disappointing, but not surprising in the least.

Shall we move this discussion to the mailing list? Otherwise we'll end up with dozens of individual PR threads.

Lastique commented 3 years ago

Is it possible to add support for Drone with a single config file (yaml), according to https://docs.drone.io/yaml/ and similar to other CIs? I don't like the need to learn yet another exotic scripting language, especially given that there seems to be no docs for this format. Also, I'd prefer to avoid the dependency on boost-ci.

sdarwin commented 3 years ago

Is it possible to add support for Drone with a single config file (yaml),

The drone server is already able to parse .drone.yml files as well as .drone.star files. The problem is the yaml file is long, verbose and repetitive. Travis supports matrix builds, which are brief and clear. Drone's solution for matrices is starlark or jsonnet, powerful scripting languages. Starlark docs are here https://docs.bazel.build/versions/master/skylark/language.html . Starlark is essentially the same as python.

I'd prefer to avoid the dependency on boost-ci.

The boost-ci drone files are in https://github.com/boostorg/boost-ci/tree/master/ci/drone . The quick one-time steps to remove that dependency would be: