-
I added a pre-checkout step in an attempt to debug but the
users/.ssh/known_hostsfile is not present before the checkout step runs so I was not able to manually edit known hosts.However, I was able to replace the pre-made checkout step with a manual execution step consisting of just:
git clone --recurse-submodules ssh://onedev/project .This is probably less efficient than the pre-made checkout step but it's gotten me past this problem & I'm unblocked for now but I'll keep an eye on this issue & remove this hack one we have a fix.
-
OneDev generates file
known_hostsautomatically for the host specified in propertyserver urlin system setting. Please make sure that your submodule url using same host name as server url setting. -
BTW: Agent does not need to be upgraded manually upon upgrading OneDev server, it will be updated automatically.
-
Correct: submodule url should be using same host as
SSH root urlspecified in system setting -
Previous Value Current Value Open
Closed
| Type |
Bug
|
| Priority |
Normal
|
| Assignee | |
| Affected Versions |
Not Found
|
Onedev is an amazing product & I've been using it very effectively for several months now, the CI agents in particular are very well designed & are very robust, great work! This is the first issue I've hit without a clear resolution.
I followed the manual page & added an ssh key to my build secrets for cloning a git submodule as the first step of my build pipeline. I'm running the onedev agent in an Ubuntu virtual box, from this VM I can
git cloneand I can alsosudo git clonethis submodule (I have the onedev agent setup as a systemd service so it might be running as root).Builds are immediately failing with the following error:
I modified my
/etc/hostsso thatonedevpoints to the IP of the onedev server on my local network. I can resolve this hostname on my host browser, host git, and from git in the VM.I'm not sure where the
known_hostsfile in this temp build directory is coming from, seems to be auto-generated incorrectly, I'd modify it if stuck around & persisted but looks like it needs to be reset somewhere upstream.I first hit this error against the
1dev/server:7.4.20docker container, I just upgraded to1dev/server:7.7.13& installed the new agent provided by the web ui but this issue persists.Fwiw, I'm on a local network working on relatively harmless projects so I seriously doubt I'm actually being MITM attacked, but who knows.
If there's any other helpful info I could provide please let me know & thanks again for maintaining such a fantastic product :)