search

HDFGroup / h5pyd

h5py distributed - Python client library for HDF Rest API
Other
114 stars 38 forks source link

Provide a method to contributors to run unit tests prior to submitting a pull request #74

Closed JacobDuckett closed 4 years ago

JacobDuckett commented 4 years ago

It seems that there's no real way to run the unit tests from my side prior to submitting a pull request. This makes it difficult to provide clean commits & PRs without the risk of having to reset, update, and submit multiple PRs to see if the tests will pass.

Some options: Build mock objects, though this is difficult to synchronize with hsds.

Provide access to test Kita server. Probably the most robust solution but I'm not sure how exposed you want the server. Might cause issues if data is written or modified incorrectly.

Provide a method to spin up a local hsds test server. This would benefit those who might be using h5pyd in systems not connected to the internet.

jreadey commented 4 years ago

What I do now is use a local HSDS server. With the compose file that includes the openio container (https://github.com/HDFGroup/hsds/blob/master/docker-compose.openio.yml), it's easy to spin up a server instance using local storage. @JacobDuckett - have you tried this yourself when working on h5pyd? Let me know if here are rough spots we need to address.

One problematic aspect is that Travis is using the KitaLab HSDS server - so if the server is down, or overloaded, there can be problems. On Travis we build and run h5serv in the travis job - it may be possible to do the same with hsds. This will also be a useful verification that everything can be setup without manual steps.

Re: Mock objects: That would be useful, but sounds like it would be a fairly high effort and would require effort to keep into synch with HSDS.

A Mock server would be another idea. Would need some scheme where requests/responses from the real server could be captured. The mock server would return the stored response for any request that came by (or error if the request isn't found in the store). But this wouldn't be able to deal with read/write/read type of tests.

JacobDuckett commented 4 years ago

Using the command docker-compose -f docker-compose.openio.yml up I get the error message ERROR: manifest for hdfgroup/hsds:latest not found: manifest unknown: manifest unknown

I'm personally not experienced with Docker but it looks like there either needs to be a latest tag in DockerHub or that the docker-compose files need to include the explicit tag. I added :v0.5.1 to the image names in the compose file and it seems to be progressing.

jreadey commented 4 years ago

I didn't realize that without an image tagged with "latest", the pull would fail. I've just pushed a build with the latest tag, so the docker-compose should work without a tag now. I'll endeavor to update this image between official HSDS releases.

JacobDuckett commented 4 years ago

It looks like you could set up automatic builds directly in DockerHub based on tags if you wanted. We've got a few projects that use automatic builds (albeit outside of DockerHub) and it has helped speed up our deployments.

So it looks like things are working on my end, but I'm unsure of how to get/set the endpoint from HSDS that I would pass into h5pyd. Maybe just some documentation for h5pyd contributors on how to set up a local test server would be sufficient for now. It would be nice if down the road it could be wrapped up into a command-line script with arguments explicitly laid out.

jreadey commented 4 years ago

I'll look into the docker automated builds.

You followed this doc for setting up HSDS right: https://github.com/HDFGroup/hsds/blob/master/docs/docker_install.md? Somewhat funkily, you need to setup a DNS name in /etc/hosts to get things to work locally. I usually use hsds.hdf.test (i.e. this maps to 127.0.0.1).

For use with h5pyd, just set the HS_ENDPOINT to this DNS name. E.g. "http://hsds.hdf.test".

Using HS_ENDPOINT="http://127.0.0.1" doesn't work, since the nginx container gets confused.

jreadey commented 4 years ago

The .travis.yml file now creates its own HSDS instance (before it was pointing to Kita Lab service) prior to running the test suite. You can follow the same pattern for running tests locally.

jreadey commented 4 years ago

Closing - have been using Travis for a few months now - it's been very helpful for verifying pull request.