Hi Jon and Ray,
---- On Fri, 27 Dec 2024 22:10:57 -0500 Raymond Toy <toy.raymond@gmail.com> wrote ---
Here's the problem for people who have already created clones - their remote url is leveraging
git@common-lisp.net instead of
git@gitlab.common-lisp.net. I used this in my cmucl/cmucl repo and problem is resolved for that repo. How to fix it more generally, though?
Aargh. I did this. git pull complains that the connection to ssh on port 22 failed. git push just hangs for at least 30 sec. No message before I killed it.
Let's get your basic connectivity stabilized before troubleshooting that part further.
Also, for cmucl/cmucl, the runners that existed before no longer seem to be defined, so my recent push to a branch has the check jobs stalled due to no eligible runners.
I'll look into the runners issue.
Hmm. I'd look into this, but I still can't access gitlab from my browser. I even tried https://65.108.13.229. Still unreachable.
The raw IP address wouldn't be expected to bring you to the gitlab instance, as this host is set up with several virtual hosts, including the gitlab., specified by name only.
But, it still should be reachable and give some kind of response. So this again points to a recurring basic connectivity issue.
I'm going to be away for a few days so I won't be able to do any more testing. But from what I can tell, this is mostly an issue on my end. Lucky me!
Ray, I do hope (for our sake) that your basic connectivity issues are indeed on your end. For your sake, assuming it is on your end, I hope it ends up being something simple/obvious once you find it. In any case, your attempts and reports have already helped us uncover several show-stopper issues on our end.
Jon, here's a possible plan to narrow down any remaining on-our-end issues for Ray while he's away:
1. Generate a fresh ed25519 keypair (for temporary/testing use)
2. Impersonate rtoy in the gitlab instance (as an Admin, you'll see an "Impersonate" button at the upper-right in the rtoy User page)
3. Go into rtoy's "SSH Keys" in the sidebar under User Preferences (user icon under upper-left Gitlab icon) and paste the public key of the keypair from step 1).
4. Temporarily edit your home .ssh/config to specify the user rtoy and the private key from step 1) for connecting to the host gitlab.common-lisp.net.
5. Pull one of rtoy's repositories, make a new branch and make an innocuous change on that branch, try to push.
if the above works, then we can assume that any remaining problems are indeed with Ray's local config. First step there is to figure out his basic connectivity issue manifested by not even being able to visit gitlab.clnet. Make sure he can reliably visit gitlab.clnet in the browser before proceeding with the next step. Next step: share the above private/public keys with Ray along with your .ssh/config entry and have him try with that setup.
Note that following the above steps will not enable actually ssh'ing into the host -- that would require also adding the public key to rtoy's .ssh/authorized_keys (you can test that too if you'd like).
If you have other ideas, please follow your instinct. I will look into the runners now.
Dave