search

binder-examples / continuous-build

Show how to use continuous integration to test your dependency specifications
BSD 3-Clause "New" or "Revised" License
8 stars 10 forks source link

adding REPO_NAME to config #4

Closed vsoch closed 6 years ago

vsoch commented 6 years ago

This PR should be enough (defining REPO_NAME in the config) to set the example repository as a default to build the notebook from. The user still would need to define DOCKER_USER and DOCKER_PASS and CONTAINER_NAME in the environment variables (the last one could also be defined in the config). I had first thought that we would want an undefined REPO_NAME to trigger an error, but maybe it's best for the default to just build an example (and then not deploy). Anyway, let's try this.

vsoch commented 6 years ago

okay so it looks like we do need to define some repo (I can't just leave as empty)

fatal: The empty string is not a valid path
Failed to clone repository!Exited with code 1

Should it assume $PWD if this is the case?

vsoch commented 6 years ago

It wouldn't make sense to give the name of the present repo, since it's already cloned it and is building from a PR (and would clone the last version)

vsoch commented 6 years ago

I'll try the path, per instructions in the docs!

jupyter-repo2docker <URL-or-path to repo>
vsoch commented 6 years ago

woo it's building now!! :popcorn: :popcorn: :popcorn:

vsoch commented 6 years ago

okay everyone should check this out :)

docker pull vanessa/repo2docker
docker run -it --name repo2docker -p 8888:8888 vanessa/repo2docker jupyter notebook --ip 0.0.0.0

Note that by default the container is built with the tag (not latest) but I tagged the version and pushed to latest because this is my preference for the user to not need to enter a tag. I know, terrible.

vsoch commented 6 years ago

This has given me immeasurable joy today, thank you <3

betatim commented 6 years ago

I think we are ready to merge this?!

vsoch commented 6 years ago

:crossed_fingers: !

vsoch commented 6 years ago

I'm way excited for this - I was able to get the repo2docker container to deploy from my local machine onto a slurm node --> https://github.com/drorlab/forward/pull/12 so a researcher can (sort of) treat an old school slurm cluster like a container one! It needs more testing wrt the build step though - and I can open an issue to discuss this. Basically, Docker lets you write anywhere (so a random /home/username to put the virtual environment and notebook files is ok) but with Singularity conversion, the user doesn't have permission to write there. As a workaround I was able to bind the files that need write (/home/userhome/.local) to the user's actual home .local (./home/<username/.local) and then set the container --home to be the actual user home (as it was getting overridden by $HOME in the container) and this works like a charm, but lost is the ability to open up and edit the previous notebooks. So - what I think is needed is a builder template for Singularity that takes these things into account. I don't know what to do yet because we can't predict a user's home in advance, but likely creating / using a location with read/write permissions for all would do the trick.

betatim commented 6 years ago

:shipit: thanks for the patience!

vsoch commented 6 years ago

wouhou!