Add docker-compose yml to facilitate accessing notebook for local testing

[bolliger32]

Summary

I found out how to use docker-compose and seems like if you want to test out new functionality by running the servers locally on a container. Not sure this actually has benefit for the worker, because it just loads and exits (no jupyter lab to run) so I only have docker-compose.yml for the notebook. But if you install a new package on the notebook and want to actually log onto the notebook to see if that package works, this will let you easily do that by using docker-compose up. If there's a better way to do this, feel free to just deny this PR.

Oh and I also just changed the execute permissions of test_pairing.sh b/c anyone should be able to execute that locally for testing.

[delgadom]

Looks cool! I had instructions for local builds in CONTRIBUTING.md. If this is an easier workflow (and it looks like it is) will you update those docs? Also, that workflow did test out the notebook:worker pairing. It it possible to test that out with this setup?

[bolliger32]

Looks cool! I had instructions for local builds in CONTRIBUTING.md. If this is an easier workflow (and it looks like it is) will you update those docs? Also, that workflow did test out the notebook:worker pairing. It it possible to test that out with this setup?

Ah I'm an idiot - I didn't even see CONTRIBUTING.md. I think that's a better workflow. The only thing this did was let you quickly start a notebook server and access that. It didn't allow any notebook-worker communication (although I'm sure there's probably a way to do that with docker-compose). I think I should probably just delete this branch and PR and stick with what you've got in the CONTRIBUTING doc. What do you think?

[delgadom]

up to you. the compose workflow certainly seems like an easier way to spin up a quick test deployment. I'd be up for migrating over to compose if we can figure out how to get the worker:notebook pairing to work with it. I haven't had a chance to play with this yet but i'd be down to merge this for now and put changing the recommended way on a slow burn. what do you think?

[bolliger32]

yup sounds good.

…

On Tue, Nov 20, 2018 at 7:30 PM Michael Delgado ***@***.***> wrote: up to you. the compose workflow certainly seems like an easier way to spin up a quick test deployment. I'd be up for migrating over to compose if we can figure out how to get the worker:notebook pairing to work with it. I haven't had a chance to play with this yet but i'd be down to merge this for now and put changing the recommended way on a slow burn. what do you think? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#79 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AElDlmpUXIP6BqXrNk1AhRZ2BRDxizkiks5uxMjOgaJpZM4YoLYQ> .