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
database/sql: resurrect go-sql-test with modern container things #19886
Comments
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. |
@kardianos owns database/sql these days, and especially so while I'm on paternity leave. |
@kardianos Is this something you need someone to work on? I have some time to put into it but I need to know if I'm going about it the right way. |
@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).
|
That output looks great, for at least a first pass. I'll ping go-dev and see if they would be willing to allocate some CPU time to test this, and if so, what a good environment would be to run this in. |
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?
/cc @kardianos
The text was updated successfully, but these errors were encountered: