Как организовать удаленные git-репозитории и работу с ними?

что бы не через scp код c/на кластер перебрасывать

CI/CD спасёт отца русской демократии, хоть тот же jenkins или teamcity.

А можно без дополнительных свистелок? Неужто гит сам не способен решать описанные проблемы?

Спасибо кэп. И чё мне дальше с двумя удаленными репозиториями? Как их синхронизировать, как как не забыть делать пуш в оба?

Неужто гит сам не способен решать описанные проблемы?

А должен? Это не его задача.

Хочется простых вещей, что бы не через scp код c/на кластер перебрасывать а делать git push/pull

Всё-таки не зря у меня к тебе комментарий стоит, не зря.

Ты просил сценарий работы через git push/pull, вот тебе сценарий работы. Разрабатываешь, как обычно. Когда нужно положить изменения на кластер, пушишь в cluster.

как не забыть делать пуш в оба?

Я прям даже не знаю. Коммиты создавать ты не забываешь? В удалённые репозитории тоже пушишь после этого. В чём проблема запушить ещё в один репозиторий перед деплоем? Тем более, всё это можно в скрипт завернуть, которым ты деплоишь и запускаешь на кластере. Вот вообще не вижу, где там могут проблемы возникнуть.

Ок, спасибо.

Я просто думал что у Гита там какое то зеркалирование репозиториев есть и вот это все ..

Самое забавное, что в гите уже есть всё нужное, но ТС хочет это сделать не прямым способом, а обратным. Чтобы на кластере можно было сделать git pull, и подтянулись изменения с машины, с которой он по ssh зашёл. Но на кластере нет интернета, поэтому для соединений наружу нужно будет пробрасывать порт через ssh. А потом ещё с кластера ходить через этот туннель на локальную машину по ещё одному ssh.

Всё это вместо того, чтобы запушить из локальной репы на кластер через ssh.

Главное не спрашивать у него, как он любит сексом заниматься.

в гите у remote внезапно может быть несколько урлов. git remote set-url --add ... и т.д., man git-remote в общем.

Плюс, поскольку на кластере будет bare репозиторий, для него нужно будет не забыть настроить worktree.

думал что у Гита там какое то зеркалирование репозиториев есть

Есть. git push --mirror. В документации есть детали.

Вот только не надо мне приписывать свои фантазии:-)

Сегодня твоя очередь спрашивать.

Не особо представляю с чем у вас возникли сложности - я вот не могу придумать решений которым недостаточно push/pull. Выбирайте:

• Каждый (физический) юзер делает себе отдельный чекаут на кластере, push’ит туда и оттуда запускается.
• Если нужно запускать централизованно, на кластере создаётся bare репозиторий в который юзеры пушат также как и в основной + машинерия которая чекаутит и запускает код оттуда.
• Сервер с bare репозиторием учится ходить на кластер (создаёте ключ, кладёте fingerprint в authorized_keys на кластере - т.к. там пользователь один вы может это сделать без проблем), по коммиту в master или production ветку он раскладывает и запускает код по ssh любым удобным способом.
• Основной bare репозиторий переносится на кластер. В старой локации удаляется или обновляется как бог на душу положет, или она учится ходить на кластер и зеркалить оттуда как в предыдущем пункте.
• Можно сделать себе pre-push хук который при пуше в основной репозиторий также пушит и на кластер.
• Ещё миллион способов, возможно требущих написать скрипт, хук или алис в пару строчек, возможно нет, но всё равно сводящихся к тому что ничего кроме push делать не нужно будет.

Не особо представляю с чем у вас возникли сложности - я вот не могу придумать решений которым недостаточно push/pull.

Спасибо. Сложности наверное с нехваткой опыта/воображения/образования - я такие проблемы никогда не решал.

Я пока склоняюсь пожалуй к варианту с хуком на сервере (или как оно там называется), но есть нюанс - связь сервера с кластером не очень устойчивая и там еще какая то байда то ли с правами то ли еще с чем:

server$ git push --all cluster
Подсчет объектов: 5506, готово.
Delta compression using up to 8 threads.
Сжатие объектов: 100% (4756/4756), готово.
Запись объектов: 100% (5506/5506), 10.29 MiB | 6.65 MiB/s, готово.
Total 5506 (delta 4236), reused 1076 (delta 743)
packet_write_wait: Connection to 10.42.180.207 port 22: Broken pipe
fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly
server$ git push --all cluster
Authentication failed.
fatal: Не удалось прочитать из внешнего репозитория.

Удостоверьтесь, что у вас есть необходимые права доступа
и репозиторий существует.

При этом он таки данные в репозиторий залил.

Gitlab и его встроенный ci/cd уже советовали?

в гите у remote внезапно может быть несколько урлов.

Спасибо, попробую.

Дядя Ринат, а в чем смысл? Запушил он в bare-репозиторий «на кластер», а дальше-то что? ТС же не за ответом на вопрос пришёл, ему надо узнать че он хочет и весь workflow аргументированно на помойку отправить, а тут ты со своими формальным ответами.

Спасибо, даже просмотр некрогомозооалиенфромаутерспейс-порно не так пагубно влияет на психику.

а в чем смысл? Запушил он в bare-репозиторий

А, да. --bare надо убрать. Сделает checkout нужного, и будет у него рабочая копия нужной версии.

А в рабочую копию пушить нельзя.

Хм. А так? git config --local receive.denyCurrentBranch ignore

Нууу, ЕМНИП, refы в .git подъедут, бранч сдвинется, может даже HEAD сдвинется, но сам чекаут останется как был. И это хорошо.

Формально, после этого ещё можно будет сделать git reset --hard, но вообще-то ты прав. Думаю, что ситуацию можно спасти, оставив репозиторий голым, но настроив post-receive.

А в рабочую копию пушить нельзя.

Это вот кстати меня всегда несколько удивляло. Почему? Типа ее можно при этом запороть?

«Чтобы она у тебя под ногами не менялась от какого-то spooky action at the distance» - уже благородная цель сама по себе. Добавим это к тому, что операции на рабочей копии могут приводить к конфликта, требующие интерактивного разрешения - че в таком случае делать будешь?

не понял причём гит и зачем тащить исходники в кластер..

разработчики продолжают ковыряться в своих локальных версиях, но для запуска+отладки предоставлен теперь кластер (видимо софт большой, или сделан для кластера).

По моему скромному мнению у разработчиков поменялись скрипт для запуска/отладки run.sh debug.sh.

вы же им не build-server с доступом через жопу добавили :-)

Код зачастую правится прямо на кластере, так быстрее (хотя м.б. это и неправильно).

Исходники тащатся на кластер потому что код собирается на кластере, да код именно кластерный/суперкомпьютерный.

Скрипта для запуска нет.

Еще проблема - один разработчик работает с разных машин (4х как мин), но доступ к кластеру есть только с одной.

значит это не проблемы git - это проблема организации процесса. Сугубо внутреннее дело компании.

Вообще код не должен правится «прямо на кластере».

ps/ на целевой машине (кластере в вашем случае) исходников и следов от сборки не должно быть никогда.

Интересно. И как тогда собирать код, если каждая целевая машина имеет свои особенности (версии библиотек, MPI, платные компиляторы и т.д.)?

Я прошу прощения за дурацкий вопрос, я совсем не программист и не системный администратор:-(

Делаешь git pull, потом git push cluster.

Всё-таки не зря у меня к тебе комментарий стоит, не зря.

Покажи)

Это как бы очевидное решение и мы пока на нем остановились. Но стало прямо интересно как это делают правильно:-)

Так и делают

Покажи)

«зашкаливающее самомнение, упёртость»

Спасибо:-)