search

influxdata / flux

Flux is a lightweight scripting language for querying databases (like InfluxDB) and working with data. It's part of InfluxDB 1.7 and 2.0, but can be run independently of those.
https://influxdata.com
MIT License
767 stars 154 forks source link

Ensure that all sql drivers are tested in integration tests #2006

Closed jsternberg closed 4 months ago

jsternberg commented 4 years ago

All of the sql drivers need integration tests that can be used against the actual database implementations. We are going to need this kind of framework in the future for other implementations like the promql transpiler, influxql, and whatever other sources we interact with.

This will likely involve creating docker sidecars as part of the integration test.

This issue is specifically about testing mysql and postgres.

This will need to be separated from the other unit tests in some way just so we don't need to run them on our local machines. If the tests don't take too long, it is ok if they are run by default in CI. If they do take more time to run (such as maybe >1 minute), then it is ok if they only run when a commit lands on master.

The only requirement is that they must be run before we perform any kind of release.

onelson commented 1 year ago

The initial lift towards this was done in https://github.com/influxdata/flux/pull/4317 and there were a handful of follow-up PRs to add additional backend support for the problem cases encountered along the way.

The status quo gives us the ability to run local integration tests against a non-exhaustive list of supported backends. We have internal docs on how to manually test some cloud-based backends (such as Google BigQuery, Snowflake).

The docker setup for certain backends required modification of the container fs in clumsy ways to configure them. The workflow also relies on docker exec to seed initial test data in already running instances. These aspects are barriers to getting this going in CI since approaches to smooth this over involve a combination of publishing custom docker images per backend (to help automate the configuration steps) or perhaps a CI environment where we can do docker-in-docker (DinD) to more closely resemble the local workflow.

Futhermore, some backends (notably Vertica and HANA) take minutes (3-5) to start up and become ready for connections, adding to the pain should we want to make this a barrier in CI.

github-actions[bot] commented 4 months ago

This issue has had no recent activity and will be closed soon.