#227 use Github Actions for CI

[SingingBush]

Opened this as a work in progress so you have visibility on it. When the issue with dmd 2.095 up is resolved I'll rebase and continue.

I'm not keen on the current tests, the configs for unittest-vibe and unittest-vibe-ut are both for integration tests against a real mysql db. I propose pulling that out into a separate test project. The only tests that should be in the code base should really be unit tests. Perhaps that's something for a future pull request.

[Geod24]

Note that one major downside of Github actions (the only significant one, IMO) is that you can't retry a single matrix row. So if the tests can spuriously fails, you better separate it in multiple workflows (this can be done trivially, but turning the whole thing into a local action and then using that from different workflows which just define the matrix variables). But if the test suite rarely / never spuriously fails, then you'll be good.

[Geod24]

Note that this is already part of the display name in the Github UI so it might be redundant.

[Geod24]

Instead of duplicating the code you can add matrix row via include: https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#example-including-new-combinations

[SingingBush]

the include/exclude options look handy I'll take a look once I've finished getting the tests running. I hate that the supposed unit tests are actually integration tests but would like to run them at least before moving things around.

So far I feel the changes are a lot better than the travis builds. I currently have (https://github.com/SingingBush/mysql-native/actions/runs/867000447) 60 jobs running in about 3 minutes, which includes running the example code against MySQL:

[Geod24]

The only tests that should be in the code base should really be unit tests.

Amen to that. Phobos has this issue as well. If it does IO, it's not an unittest.

[SingingBush]

Removed travis file and a load of related scripts that are now redundant. As well as building on a bunch of compiler versions from 2.080 to latest on multiple platforms it also runs the unittest-vibe-ut config on D 2.083 to latest (unit-threaded doesn't like older), and also runs the example project. See passing builds here:

https://github.com/SingingBush/mysql-native/actions

It would be good to extract some of the test code and make the example project a little more robust. I can help with that as well but it would need this merging first really. There's more to do but this pull request is already fairly large so would rather have this merged then follow up with other changes.

[schveiguy]

Looks pretty good. It looks like you are testing with mysql for integration tests, but not mariadb (which seems to be a focus from Nick). I want to keep that at least. Is there a github action mechanism to try mariadb?

I will work on extracting the integration tests.

[SingingBush]

Looks pretty good. It looks like you are testing with mysql for integration tests, but not mariadb (which seems to be a focus from Nick). I want to keep that at least. Is there a github action mechanism to try mariadb?

I've split it into two files now:

• dub.yml is basically just ensuring that the codebase can build with a bunch of different compiler versions
• integration-testing.yml is running code (currently both unittest-vibe-ut and the examples) against an actual database

In integration-testing.yml it's running against MySQL 5.7 and Mariadb 10 for now. It's easy to add other versions and I've commented out a block that can be used for testing MySQL 8 once it's supported

[schveiguy]

I'm currently trying to extract all dub configurations that make no sense to be in the library to a separate folder, including the app.d which is troublesome here.

The integration tests are interspersed throughout the code base, which makes them difficult to extract without ripping them away from the items they are testing. The mysql/test package should be completely extracted. I'm still pondering how to do that, but I do want to do it. At the very least, I want to remove the dependency of unit-threaded from the main library.

[SingingBush]

ok, so can this be merged in the meantime?

[schveiguy]

I will merge this, but 2 things:

1. Can you re-add the code that was deleted in ci_setup.d and run_tests.d? They don't have to be used, but I don't want to lose them. The batch/shell script that compiled it can be left out though.
2. Can you explain what all the dub.selections.json files you removed were used for? I'm having trouble understanding the existing system.

[SingingBush]

Why add them back? it's in the git history so it can be viewed any time. The dub.selections.json was used because before there was a desire to support so many versions of D that you had to have different versions of vibe-core because they don't support as many compiler releases as this project attempts to do. It was pull #215 that added them. There was some logic in ci_setup.d that made use of them:

	if(envGet("DUB_SELECT") != null)	{
		string dubSelections = "dub.selections."~envGet("DUB_SELECT")~".json";
		writeln("Using alternative dub dependencies file: ", dubSelections);
		copy(dubSelections, "dub.selections.json");
		copy("examples/homePage/dub.selections."~envGet("DUB_SELECT")~".json", "examples/homePage/dub.selections.json");
	}

That's overkill though, simply reducing the scope of compiler versions to support does away with multiple problems as it'll bring your project inline with compilers that your dependencies support.

[schveiguy]

Why add them back?

I will add them back later.

If they are not there, I'll forget about them, since I am super unfamiliar with the way testing is done here. I have a feeling we are going to pretty much have to start over...

[SingingBush]

no prob, putting it back now