"start" file doesn't play nicely with "-E" if executable permissions aren't set

trying to get a gallery of notebooks working well with repo2docker

fwiw, the repo is here, currently on the branch “reorg”

https://github.com/AllenInstitute/brain_observatory_examples/tree/reorg

I need to specify an environment variable that is stable for all of the notebooks, and I’ve defined this using the “start” file:

#!/bin/bash
export BRAIN_OBSERVATORY_MANIFEST=~/brain_observatory_data/manifest.json

exec "$@"

This works beautifully when running repo2docker . & I can confirm that the environment variable is set properly.

However…

I’m not 100% sure that all of these notebooks work together (same set of dependencies, etc). I would like to spin them up in repo2docker in editable mode, make sure they all run, make any changes necessary, shut it down, then commit any changes back to the repo.

However, when I run this in editable mode repo2docker -E ., I get an error and the docker container doesn’t run:

Step 33/35 : RUN chmod +x "./start"
 ---> Running in 44557a8fa7e5
Removing intermediate container 44557a8fa7e5
 ---> 9b35a30889e3
Step 34/35 : ENTRYPOINT ["./start"]
 ---> Running in 5ab226e6dc83
Removing intermediate container 5ab226e6dc83
 ---> 8e17f62aace0
Step 35/35 : CMD ["jupyter", "notebook", "--ip", "0.0.0.0"]
 ---> Running in af6f7ad1d36f
Removing intermediate container af6f7ad1d36f
 ---> 356a160c50a3
{"aux": {"ID": "sha256:356a160c50a3c985d6a24e96f5c4e56201ec1105e7b471ca57a1629ba62224e9"}}Successfully built 356a160c50a3
Successfully tagged r2d-2e1542325997:latest
Traceback (most recent call last):
  File "/home/justink/anaconda3/lib/python3.6/site-packages/docker/api/client.py", line 229, in _raise_for_status
    response.raise_for_status()
  File "/home/justink/anaconda3/lib/python3.6/site-packages/requests/models.py", line 935, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 400 Client Error: Bad Request for url: http+docker://localhost/v1.38/containers/b26d31fbb36e7b3e761fe86ae95ecfa1006840e9fc5b8d18be2f16b587f5543c/start

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/justink/anaconda3/bin/repo2docker", line 11, in <module>
    load_entry_point('jupyter-repo2docker', 'console_scripts', 'repo2docker')()
  File "/home/justink/Code/repo2docker/repo2docker/__main__.py", line 7, in main
    f.start()
  File "/home/justink/Code/repo2docker/repo2docker/app.py", line 756, in start
    self.run_image()
  File "/home/justink/Code/repo2docker/repo2docker/app.py", line 572, in run_image
    container = self.start_container()
  File "/home/justink/Code/repo2docker/repo2docker/app.py", line 634, in start_container
    environment=self.environment
  File "/home/justink/anaconda3/lib/python3.6/site-packages/docker/models/containers.py", line 772, in run
    container.start()
  File "/home/justink/anaconda3/lib/python3.6/site-packages/docker/models/containers.py", line 374, in start
    return self.client.api.start(self.id, **kwargs)
  File "/home/justink/anaconda3/lib/python3.6/site-packages/docker/utils/decorators.py", line 19, in wrapped
    return f(self, resource_id, *args, **kwargs)
  File "/home/justink/anaconda3/lib/python3.6/site-packages/docker/api/container.py", line 1064, in start
    self._raise_for_status(res)
  File "/home/justink/anaconda3/lib/python3.6/site-packages/docker/api/client.py", line 231, in _raise_for_status
    raise create_api_error_from_http_exception(e)
  File "/home/justink/anaconda3/lib/python3.6/site-packages/docker/errors.py", line 31, in create_api_error_from_http_exception
    raise cls(e, response=response, explanation=explanation)
docker.errors.APIError: 400 Client Error: Bad Request ("OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"./start\": permission denied": unknown")

I’m running repo2docker on master.

Any thoughts?

[neuromusic]

awesome. I’ll try to dive in the next week or two, before my new job starts

[neuromusic]

oh, I see. you’re right. Gitkraken simply didn’t notice the permissions change, but I could commit it with vanilla git. that’s what I get for using a GUI.

checking and erroring out makes sense to me.