SlavikF

Сообщение "Host key verification failed." говорит о том, что до проверки ключа пользователя (SSH_PRIVATE_KEY) дело не доходит, потому что всё тормозится на проверки фингерпринта сервера (SSH_KNOWN_HOSTS)

В той же статье там написано про то, что с этим делать:
https://docs.gitlab.com/ee/ci/ssh_keys/README.html...

Ещё есть вариант игнорировать фингерпринт хоста:
ssh -o StrictHostKeyChecking=no ****@**** ls
Но это несекъюрно - можно попасть на MITM.

Простой ответ:
- Ставите gitlab-runner на vds
- Пишете .gitlab-ci.yml конфигурация для проекта

Но так как вы:

так и не смог разобраться

То я думаю вам надо нанять консультанта.
Потому что у вас вопрос задан так, что похоже что вы просите написать серьезный tutorial.

Как тут уже писали, один вариант - это вебхук.

НО git pull на продакшене - не очень хорошая идея, потому что у вас на проде будет копия репы. Это не очень хорошо и секъюрно.

Best practice:
- вы делаете git push в репу (или merge PR)
- если надо, то CI система делает build
- CI копирует нужные файлы (артифакты) на прод. С помощью rsync, scp, ftp, чего угодно. Обычно при этом на прод нужно добавить каких-то ключей, паролей и т.д., который нет в репе, но у CI они есть (из настроек, ввод пользователя, из Vault, ...)

Да, помню как-то ломал голову над этим, но в конечном итоги оказывалось, что есть какой-то вариант, что разработчик может получить доступ к продакшн-серверу.

Тогда я решил это тем, что у основного проекта был доступ только к staging, а для прода был форк этого проекта со своим раннером.

Но после этого у Гитлаба добавили несколько фишек, то может теперь и есть и другой вариант.
Сегодня я думаю можно так:
- иметь 2 раннера: один для staging, один для production
- раннер для production поставить разрешение запускать только на `master`
- у разработчика нету привилегий для доступа к `master`.

При этом подразумевается, что staging и production - это разные серверы.