Refactor drone CI integration

Flamefire commented 2 years ago

The readme says:

Copy the .drone.star file and .drone directory from this repository to the top level of your repository.

So what will happen is that e.g. linux_cxx will Pull down Boost.CI: https://github.com/boostorg/boost-ci/blob/4ed2aa3e9c7b21c7b5e8dd3f437dd9e3725b7667/ci/drone/functions.star#L61

And the current example drone file will do that again: https://github.com/boostorg/boost-ci/blob/4ed2aa3e9c7b21c7b5e8dd3f437dd9e3725b7667/.drone/drone.sh#L21

So this duplicates work wasting resources.

Furthermore the Drone config is much less readable than e.g. the Github config

@sdarwin Could you work on the first part, i.e. that it downloads Boost.CI at most once and only if not running on Boost.CI? I don't understand why we would need .drone/boost-ci and ci when having the latter is enough (see e.g. Github actions)

I started work on an improved drone config in a branch

sdarwin commented 2 years ago

wasting resources

In that first case, it could probably pull down the file it needs, the small text file linux-cxx-install.sh, instead of the whole repo. this sort of syntax, generally.

 run: wget "https://raw.githubusercontent.com/boostorg/release-tools/python3/ci_boost_common.py" -P ${HOME}

DRONE_JOB_UUID was an artifact of the travis import to be able to deal with exceptions that correlated to a particular job. To clean up the drone config now, DRONE_JOB_UUID can likely just be deleted.

Flamefire commented 2 years ago

In that first case, it could probably pull down the file it needs, the small text file linux-cxx-install.sh

Ok working on that: https://github.com/boostorg/boost-ci/tree/drone_fix-double-clone

2

No I meant compare the Drone config:

linux_cxx("gcc 12", "g++-12", packages="g++-12", buildtype="boost", buildscript="drone", image="cppalliance/droneubuntu2204:1", environment={'B2_TOOLSET': 'gcc-12', 'B2_CXXSTD': '17,20', 'DRONE_JOB_UUID': '17ba079179'}, globalenv=globalenv),
  linux_cxx("clang 3.8", "clang++-3.8", packages="clang-3.8", buildtype="boost", buildscript="drone", image="cppalliance/droneubuntu1604:1", environment={'B2_TOOLSET': 'clang-3.8', 'B2_CXXSTD': '03,11', 'DRONE_JOB_UUID': '7b52009b64'}, globalenv=globalenv),

to the equivalent Github config:

- { compiler: gcc-12,    cxxstd: '17,20',  os: ubuntu-22.04 }
- { compiler: clang-3.8, cxxstd: '03,11', os: ubuntu-20.04, container: 'ubuntu:16.04' }

So what I'm working on is:

    job(compiler='gcc-12',    cxxstd='11,17,20',    os='ubuntu-22.04'),
    job(compiler='clang-14',  cxxstd='11,14,17,20', os='ubuntu-22.04'),

sdarwin commented 2 years ago

compare the Drone config

A few comments.

In real production usage, the cppalliance repos, or pdimov repos, or others, have CI that is covering a wide scope of gcc and clang compilers. Not only gcc-11, gcc-12, clang-6, clang-14. Shouldn't the .drone.star file continue to have the widest range of compiler versions? If someone copies the file, they are present. It's easier to delete jobs, or comment out them out later, than to add code.
And to include the other jobs types: s390x, arm, freebsd, windows. Validate they are working.
For MacOS, while the default xcode_version="10.3" which correlates with what Travis had, the actual newest one is xcode_version="12.4". Adding xcode_version="12.4" in the new .drone.star would serve multiple purposes. It demonstrates to the user how they can adjust the xcode_version. And it pushes some traffic onto the newer machines which aren't yet busy.
Everything should still be customizable: job "name" can be specified. Great. How about the "image" field? Be able to overwrite that in a job, if necessary.
Alternatives have pros and cons. For example, here is a spreadsheet of amazon ec2 instances: https://instances.vantage.sh/ It's simple and useful, even if repetitive. In a similar way, the old .drone.star was repetitive, but also quick and easy to understand. Perhaps adding this new drone automation is better. But an easy (if repetitive) spreadsheet is nice too, the user doesn't have to reason about what the functions are doing.

Flamefire commented 2 years ago

This is the function I'm working on: https://github.com/boostorg/boost-ci/blob/drone-refactor/.drone.star#L14

Shouldn't the .drone.star file continue to have the widest range of compiler versions?

Yes: The above was just an example, I'll convert all existing ones or better maybe use https://github.com/boostorg/url/blob/develop/.drone.star as the goal (just in pretty)

Adding xcode_version="12.4" in the new .drone.star would serve multiple purposes.

I wanted to shortcut that to os='osx-12.4' or so, similar to the ubuntu ones

How about the "image" field? Be able to overwrite that in a job, if necessary.

Makes sense

But an easy (if repetitive) spreadsheet is nice too, the user doesn't have to reason about what the functions are doing.

That's what I want to get at with the new function: Don't bother authors with the details of the functions, but have a simply spreadsheet-like function to define what you want/get

sdarwin commented 2 years ago

I wanted to shortcut that to os='osx-12.4' or so, similar to the ubuntu ones

osx also has operating system versions with similar number schemes. 10.15. 12.4. Drone has been set up to make a decision based on xcode version instead, and send the user to one of three pools of servers. Not sure the best answer but it's misleading to say 'osx-12.4' because it looks so much like a real operating system version number.

The job name field has to be unique. When adding other architectures or operating systems, have to include that in the name to avoid name collisions.

Flamefire commented 2 years ago

The job name field has to be unique. When adding other architectures or operating systems, have to include that in the name to avoid name collisions.

I'm using the existing functions to create the pipelines and those add the job names

Not sure the best answer but it's misleading to say 'osx-12.4' because it looks so much like a real operating system version number.

Ok, I'll change it to "osx-xcode-12.4", I just want to remove redundancies: If you specify "xcode" you imply "osx".

sdarwin commented 1 year ago

@Flamefire maybe the cppalliance libraries (json, url, etc) drone.sh files could be refreshed. This could be the basis for the update: boost-ci's version of drone.sh.

Then, to consider what is missing, or has to change.

The new drone.sh file runs common_install.sh every time. With docs or cmake, this is not exactly the correct thing to do, right? Do you have any ideas about how to organize the file so it can run docs and cmake without common_install.sh? (or is that not a correct assumption).
Feature enhancement: add a doc build job to boost-ci drone.sh. A convenient way to do that is to use the new scripts from https://github.com/boostorg/release-tools/tree/develop/build_docs
Feature enhancement: add cmake jobs to boost-ci drone.sh.

Currently, boost-ci has example cmake tests in ci.yml, and cppalliance repositories have a few drone cmake tests. I wonder if there is a one-to-one correspondence. I hope so, it will be easier if everything is standard.

Flamefire commented 1 year ago

1. The new drone.sh file runs common_install.sh _every time._ With docs or cmake, this is not exactly the correct thing to do, right?   Do you have any ideas about how to organize the file so it can run docs and cmake without common_install.sh?  (or is that not a correct assumption).

common install does also the clone of Boost and bootstraps B2. The latter is not required for CMake but likely for the docs build, at least "my" libraries use B2 to build the docs and the partially recursive clone of Boost is required in almost all cases. There is also a $B2_DONT_BOOTSTRAP option which is used by the CMake GHA jobs.

2. Feature enhancement: add a doc build job to boost-ci [drone.sh](https://github.com/boostorg/boost-ci/blob/master/.drone/drone.sh).  A convenient way to do that is to use the new scripts from https://github.com/boostorg/release-tools/tree/develop/build_docs

Not sure how those work exactly and if we want to encode the library specific steps here. Using B2 is really convenient and can be done with the existing workflow already: https://github.com/boostorg/locale/blob/9c010b9a33a65ea49124259f15da6a1cb6946e4b/.github/workflows/ci.yml#L59-L76

3. Feature enhancement: add cmake jobs to boost-ci [drone.sh](https://github.com/boostorg/boost-ci/blob/master/.drone/drone.sh).
Currently, boost-ci has example cmake tests in ci.yml, and cppalliance repositories have a few drone cmake tests. I wonder if there is a one-to-one correspondence. I hope so, it will be easier if everything is standard.

Yes I think it makes sense to copy the CMake tests from GHA to Drone so one can run either although I'm not sure if it's worth the effort. Pretty packed with work right now and the GHA ones are working...

It might make sense to provide a cmake_job function in the functions.star.

BTW: I see you merged #200. Was there a decision which part should go to drone.star and functions.star? I don't really have an opinion here but either job_impl should go into functions.star or the 2 merged into 1 job function in drone.star. Either way is fine for me, although I'd slightly prefer the former (for easier updating all repos) which you need to do as it needs deployment

boostorg / boost-ci

Refactor drone CI integration #184