I went ahead and configured the .devcontainer setup in the following PR to use FDB from a separate container in a shared docker-compose network:
https://github.com/apache/couchdb/pull/3343 <https://github.com/apache/couchdb/pull/3343> Cheers, Adam > On Jan 22, 2021, at 8:53 AM, Adam Kocoloski <kocol...@apache.org> wrote: > > Hi, > > I noticed the test suite for 4.0 sets an application environment variable > {fabric, [{eunit_run, true}]} that results in erlfdb starting a new fdbserver > instead of using the one defined in the fdb.cluster file that it would use > otherwise. I think that’s a reasonable default especially given that many of > these tests seem to erase the entire FDB key space. I also noticed that > there’s an additional {erlfdb, [{test_cluster_file, “…”}]} environment > setting that can be used to override the behavior of starting a new fdbserver. > > As I mentioned in a recent thread I’ve been hacking on a development > container for VS Code / GitHub Codespaces to make it easier to get started on > CouchDB development. For 4.0 I’m thinking to use Docker Compose and the > official FDB image that the community posts to Docker Hub. In this setup I > think it would be better to just use the `test_cluster_file` setting to point > to the same fdbserver running in that container for unit tests rather than > start up _another_ fdbserver inside the CouchDB container, as this whole > setup is explicitly designed for development and would not be confused with > an FDB server being used for some other purpose. If that makes sense to > folks, I think my next steps would be to find a clean way to inject this > `test_cluster_file` setting into the unit test config when running in the > devcontainer. > > On a related note, I wonder if some of those tests could be refactored to > e.g. create an empty directory for the test and remove it afterwards, rather > than blowing away a whole cluster’s worth of data each time. Perhaps using a > parent “eunit_test” directory so it’d be easy to clean up if necessary? The > thinking would be that a developer could have some data in a test cluster, > run the test suite against the same FDB powering that cluster, and not lose > the data. I know there are downsides to that approach and we’d want a big red > button to reset the FDB cluster, but wanted to float it anyway. Cheers, > > Adam
