move CI from travis to github actions

[SingingBush]

A while ago I started moving hibernated and ddbc to use Github Actions instead of travis. Initially so that CI and the repo were under one roof but I found that the build times were substantially faster on github.

As an example this ddbc build runs a total of 35 builds, across Ubuntu, Mac, and Windows (64 & 32 bit) as well as one of those builds running integration tests against SQLite, MySQL, Postgres, and MS SQL Server 2017.

If you want I can put together a pull request. The yml for the ddbc pipeline looks like this: https://raw.githubusercontent.com/buggins/ddbc/master/.github/workflows/dub.yml

[schveiguy]

Thanks, yeah, I probably should just drop travis. I did just migrate to travis-ci.com, since .org wasn't completing, but now the .com isn't completing (seems to be only the Mac instances).

The whole mysql-d test system needs a complete overhaul. This is a prerequisite to merging my safe PR, so I need to pay attention to it. Thanks for the offer to set up a PR, but I think it's important for me to understand how the test system works. I do appreciate the help, and if I have questions, I'll probably post back here. I plan to tackle this in the next month.

[SingingBush]

I've put together something to get you started but I think the main issue at the minute is that builds fail for the last few releases of dmd/ldc:

I still believe that focusing on more recent compilers rather than trying to support everything since dmd-2.068 would really help this project. I've been saying that since #141 2017. Have you guys considered re-evaluating that stance? It is 2021 now so you're trying to cover 6 years worth of compiler releases!

[schveiguy]

Yes, I know CI needs work. Note that before this past November, Nick was the only one in charge of working on this, I have not looked at the CI at all.

When I do get into it, I'll probably make some executive decisions regarding what we want to support. This project hasn't fundamentally been updated since late 2019, and it needs a lot of TLC right now.

The build is kind of messy, and uses some custom D-based scripts. I need to reign all this in, and hopefully version 3.0.0 will have had all the cobwebs cleaned out. Then I'm in a position to think about what versions of both the compiler and databases we need to continue to support.

[SingingBush]

I'm happy to help out. I need this project for ddbc, which I need for hibernated, which I need for another application. I've looked at all the current CI stuff and it seems way over the top. The beauty of dub, and part of the reason I started using it, is that simply running dub build or dub test should be all someone needs to pull dependencies and get a working binary. This current setup with the run_tests scripts and having 447 lines of travis-ci.yml is nuts.

I like the Vibe-d approach of supporting the 10 latest minor releases of dmd. Keeps maintenance simpler.

Having a monthly build done by cron for dmd-latest and perhaps dmd-beta will really help catch breaking changes. There's also the option of adding this project to https://github.com/dlang/ci/blob/master/buildkite.sh so that pending compiler changes are checked with mysql-native before even being released.

I'll keep tweaking that branch of mine with a view to only support dmd-2.086.1 and above (unless you need anything older for some reason) and try and simplify things. Then at least if you like it you can pull it in.

[schveiguy]

Thank you for clarifying! I did not connect the dots that you were here because you have mysql-native as a dependency. I'm going to bump this up as a priority.

Regarding which versions of things to support, I don't want to draw exactly arbitrary lines in the sand. Especially for something like database support, I know what it's like to have your dependencies yank support for things that you don't want to have to update. But I also don't have time to spend making sure every revision of everything builds. There is quite the support matrix here already.

Good to have people who are invested here to help, thank you! I think we absolutely should add this to buildkite, as a recent dub change broke the build (see #224).

[SingingBush]

to clarify on 'supported'. I don't suggest purposefully making breaking changes, just reducing the amount of compilers that this project actively builds against and guarantees compatibility with. In hibernated I have code like this:

    static if (__VERSION__ < 2074) {
        import std.traits : FieldTypeTuple, Filter; // Filter used to be in std.traits
    } else {
        import std.traits : FieldTypeTuple;
        import std.meta : Filter;
    }

and

// For backwards compatibily
// 'enforceEx' will be removed with 2.089
static if(__VERSION__ < 2080) {
    alias enforceHelper = enforceEx;
} else {
    alias enforceHelper = enforce;
}

So it'll still work with old dmd versions potentially. It's just that the CI only runs on dmd-2.086.1 and above. If someone raises an issue for and old version of dmd that's fair enough. Potentially it can still be solved. Just don't make things harder than they have to be.

[schveiguy]

Dropping travis has become a requirement now. One build using their "credit" system consumed all the credits for free projects (no doubt due to the insane number of builds in the CI config).

I will look at this soon.