Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
database/sql: resurrect go-sql-test with modern container things #19886
https://github.com/bradfitz/go-sql-test was an effort to automate testing of database/sql against all of the out-of-tree database drivers.
Nowadays there are many more drivers: https://golang.org/wiki/SQLDrivers
But https://github.com/bradfitz/go-sql-test is old & neglected & broken. It predates Dockers (by about a year).
It should use containers and be runnable by anybody without a bunch of setup work.
Anybody have time to help?
Wanted to write about this for some time. I used self-hosted Drone CI with 60 combinations for my ORM with great success: https://github.com/go-reform/reform/blob/v1-stable/.drone.yml#L64.
What kind of infrastructure you want to use to run tests?
Hey @bradfitz, I saw this issue with HelpWanted so I started doing some work on this and what I've done so far is available here: https://github.com/xfernando/go-db-driver-tests. I have tests running and passing for two mysql drivers and two postgres drivers with everything (including the tests) running on docker containers.
I thought it'd be too much work trying to get your old repo running so I started a fresh one and copied some of your old code and refactored things a bit so it'd be easier to add tests for more drivers.
@xfernando I'm not too concerned with some implementation details at the moment. I think most of the current go build testing is run on k8s.
If I'm dreaming I would imagine being able to clone a driver repo at a specific branch, or PR and run a test against it. I would record the driver run output and store it either to a local directory or to GCE object storage. Record the location of the driver run output in a central list.
Perhaps a more modest proposal would be to spin up an image/pod once a day (as a batch a job), have it pull the latest drivers from source master, and test them and post the results to GCE object storage/file location. The output should include the git revision of each driver used and import path. If that is working, we could ask if the Go project would be willing to schedule the image to run once a day as a job.
@kardianos Option 2 is closer to what I've done.
I have a Dockerfile that builds an image with driver prerequisites (such as libpq-dev), uses
Here's the output of the container that runs the tests (I added the printing the driver's revision per your suggestion).