binder-project/binder

Failed builds: 0 bytes log and replacement of a working image with a broken one

dpiparo opened this issue · 2 comments

Hi,

congrats for the new design of the "feed" page: it looks great.
Today we encountered an issue building an image from a Dockerfile. The repository is https://github.com/cernphsft/rootbinder .
Two probably undesired things happened:

  1. When downloading the logs from the build page in order to debug the problem, an empty file was obtained.
  2. The broken image replaced the existing but working one.

I would consider 1) low priority while 2) is probably a little worse.

Cheers,
Danilo

Hey @dpiparo, sorry you're having trouble with the build. Issue 1 is caused by a timeout that's being hit on the API server due to the size of your log file (it's taking a while to extract out the relevant lines from the build file, and the default timeout is only 2 seconds).

Issue 2 does seem to be non-ideal. Especially considering the previously built image is already loaded onto the cluster, having the binder badge perform a launch with the last successful image should be fine. Right now, we're only checking on the current build's status to determine if the launch should proceed, but taking past builds into consideration would definitely be an improvement. That sound better?

These are both very small changes! Thanks for opening the issue -- we'll work on em.

To help with your debugging right now, the error I'm seeing for your build is cp: cannot create directory '/home/main/.ipython/kernels' : No such file or directory". While these changes are being made, it's probably best making any experimental changes to your Dockerfile in a separate repo while keeping your main repo stable (this would be simpler if we supported building off of branches, but, since we don't cap the number of repos you can binderize, it's a workable approach).

Hi @andrewosh ,

thanks for your quick reply.
About item 1): it was not clear if the log was lost or if I was hitting a limit. Thanks both for clarifying and for providing additional debug info.
About item 2): I agree with you. If possible, the image to be launched should be the last successfully built. For some reason I had the impression this was already the case. For now I can certainly proceed with "test builds" in case something changes and then re-build the "real repo".

Cheers,
Danilo