-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OSX: ssh docker setup is not working for maint and master #42
Comments
any immediate ideas on what is going wrong here? given that |
@yarikoptic I do not know what's going wrong. Further ad hoc customization of the SSH setup scripts would be needed in order to get any debugging information. |
Ah, let's then forget about it and wait for master release |
actually I take it back since I mixed it all up -- it works only on release and not on maint or master, so we are doomed to pin it down :-/ FWIW it seems failing differently ATM maint:==> docker-machine
Bash completion has been installed to:
/usr/local/etc/bash_completion.d
To have launchd start docker-machine now and restart at login:
brew services start docker-machine
Or, if you don't want/need a background service you can just run:
docker-machine start
Creating CA: /Users/runner/.docker/machine/certs/ca.pem
Creating client certificate: /Users/runner/.docker/machine/certs/cert.pem
Running pre-create checks...
(default) Image cache directory does not exist, creating it at /Users/runner/.docker/machine/cache...
(default) No default Boot2Docker ISO found locally, downloading the latest release...
Error with pre-create check: "failure getting a version tag from the Github API response (are you getting rate limited by Github?)"
Error: Process completed with exit code 3. master: connection refusedEND datalad-tests-ssh2 LOGS --------
nc: connectx to localhost port 42241 (tcp) failed: Connection refused
nc: connectx to localhost port 42241 (tcp) failed: Connection refused
nc: connectx to localhost port 42241 (tcp) failed: Connection refused so I guess it boils down to how datalad is installed (from pypi vs straight from git)? |
@yarikoptic Those errors are occurring before datalad is even installed. We've also known about the maint issue for a while, and it continues to fail despite doing what the docker-machine docs say. |
d'oh -- looked into our template:
that explains the difference between released or not. On released (which we should have started to test against SSH) we do not even bother to set it up for running SSH tests. So, at least that mystery is not a mystery ;) I will submit a PR now to just disable setting it up for SSH on OSX, so we get green again, but we still need to figure out WTF we fail to establish that docker container on OSX. |
For not yet known reason we have a problem instantiating a proper docker container on OSX for ssh testing. Also I found some logic which we should have removed after datalad 0.13.2 release while establishing that docker container on osx and linux -- so I removed conditional Re OSX: see #42
For not yet known reason we have a problem instantiating a proper docker container on OSX for ssh testing. Also I found some logic which we should have removed after datalad 0.13.2 release while establishing that docker container on osx and linux -- so I removed conditional Re OSX: see #42
@yarikoptic I believe I've finally fixed this. The problem was that SSH was configured to connect to localhost, but when using docker-machine, containers' ports aren't exposed on localhost, they're exposed on the IP address for the docker-machine VM. PRs: datalad/datalad#5417, #55 |
AWESOME, Thank you @jwodder ! |
Eventually we should get back to this , and either finish #55 or #58 but currently testing against datalad is still red overall since recent annex changes caused breakages, see datalad/datalad#6492 -- so we are pretty much blocked by that. We should get back to adding ssh testing as soon as datalad turns green again here. |
see e.g. https://github.com/datalad/git-annex/actions/runs/458535490 runs
did not look inside on how to resolve but must be possible one way or another (may be it is just a port conflict issue among multiple docker instances on the same box?)
The text was updated successfully, but these errors were encountered: