Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

move CI from travis to github actions #227

Closed
SingingBush opened this issue May 3, 2021 · 7 comments
Closed

move CI from travis to github actions #227

SingingBush opened this issue May 3, 2021 · 7 comments
Labels

Comments

@SingingBush
Copy link

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
Copy link
Collaborator

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.

@schveiguy schveiguy added the tests label May 3, 2021
SingingBush added a commit to SingingBush/mysql-native that referenced this issue May 7, 2021
@SingingBush
Copy link
Author

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:

image

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants