Есть ли способ заставить Git загружать клиентские хуки как действие предварительного получения с сервера? - PullRequest
1 голос
/ 27 февраля 2020

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

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

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

2.- Нам необходимо постоянно обновлять эти хуки из центрального местоположения

3.- Все это должно произойти после того, как пользователи попытаются сделать pu sh, но до распаковки изменений

Связать это со скриптом сборки или модифицировать репозитории было бы абсолютно нет, так как я не хотят загрязнять репозитории пользователей, и в идеале это должно быть абсолютно прозрачным для пользователей, в таким образом, что они даже не знают, что обработка этих правил выполняется на их стороне, и что она защищена от несанкционированного доступа (т. е. как пользователь, я go захожу в мою локальную директорию хуков и модифицирую скрипт).

Любая идея, если это можно сделать с помощью какого-то неясного механизма Git, инициируемого на сервере в режиме предварительного получения или аналогичного хука ?, или, возможно, какое-то лучшее решение, даже если подход совершенно другой?

Я устал объяснять пользователям, что Git не для хранения двоичных файлов, особенно для выпуска двоичных файлов (многие из наших пользователей происходят из-за этой ужасной практики в SVN, P4) ... это влияет на наш Git сервер, и начинает раздувать время их сборки ... что они потом обвиняют в этом.

Как вы уже догадались, я работаю в ИТ, и да ... мы пытались выключить и включить наш сервер.

enter image description here

1 Ответ

0 голосов
/ 09 марта 2020

Краткий ответ:

Нет. Нет встроенной функции git, которая позволяла бы незаметно устанавливать клиентские хуки с сервера.

Длинный ответ:

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

Полное раскрытие информации: я работаю в команде поддержки Premier Atlassian и очень тесно сотрудничаю с разработчиками Bitbucket Server. Сказав это, это почти полностью вопрос git, а не Bitbucket, поэтому я сосредоточусь на этом здесь.

Вариант 1: переопределить core.hooksPath

(см. Также : https://git-scm.com/docs/githooks)

По умолчанию git ищет хуки внутри вашего хранилища в $GIT_DIR/hooks/*. Это настраивается как на уровне репо , так и на на глобальном уровне. Настроить это глобально довольно просто:

git config --global core.hooksPath /path/to/custom/hooks

Это даст более или менее немедленный эффект для всех репозиториев, как новых, так и существующих. Вам нужен какой-то способ запустить это на рабочей станции каждого члена команды, но в большинстве корпоративных сред уже есть методы запуска сценариев и т. Д. c. удаленно, так что на самом деле это всего лишь вопрос убеждения вашей ИТ-команды администратора в том, что это необходимое бизнес-требование.

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

Если вы хотите попробовать настройку core.hooksPath на локальном компьютере, выполните следующие действия:

$ mkdir ~/.globalgithooks
$ echo "printf 'hello world\n'" > ~/.globalgithooks/pre-commit
$ chmod +x ~/.globalgithooks/pre-commit
$ git config --global core.hooksPath ~/.globalgithooks

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

Плюсы:

  • Действует как для текущих , так и вновь созданных репозиториев

Минусы:

  • Удаляет возможность настраивать крючки для каждого репо

Опция 2: переопределить git template dir

(см. также: https://git-scm.com/docs/git-init#_template_directory)

Когда вы создаете репозиторий, git не просто устанавливает его из " ничего"; он использует предварительно упакованный каталог шаблонов, который содержит (чтобы процитировать вышеупомянутую ссылку) «некоторую структуру каталогов, предложенные« исключить шаблоны »и образцы файлов ловушек». Вы можете добавить свои собственные пользовательские перехватчики в этот каталог шаблонов, и всякий раз, когда создается новый репозиторий, они будут копироваться в локальный набор перехватов этого репозитория ($GIT_DIR/hooks). Интересный факт: даже когда вы клонируете репозиторий, вы все равно создаете «новый» - это просто новый репозиторий, который git добавляет затем удаленный URL-адрес восходящего потока, выбирает объекты и проверяет ветку по умолчанию. Другими словами, каталог шаблонов по-прежнему используется при клонировании, поэтому созданные для него пользовательские хуки будут автоматически настроены для любого репозитория, созданного путем клонирования.

Опять же, вам потребуется некоторый управляемый доступ к вашим машинам. сделать это. Однако это, возможно, сложнее, чем первый вариант; где с опцией 1 вы можете просто скопировать ваши хуки в любое удобное для вас место и запустить простую команду git config, чтобы эта опция работала, вам нужно найти правильный каталог шаблонов для установки git этого пользователя. Учитывая множество способов git, которые могут быть установлены в разных операционных системах и разными менеджерами пакетов, это означает, что вам нужно определить, где находится каталог. По умолчанию в Linux это /usr/share/git-core/templates; в моей домашней установке на macOS это можно найти либо по /usr/local/Cellar/git/$GIT_VERSION/share/git-core/templates со ссылкой c в /usr/local/share/git-core/templates… другими словами, вам нужно собрать воедино какую-то логику c, чтобы найти нужную поместите и добавьте свои крючки там. И даже в этом случае это не повлияет на любые существующие репозитории, уже находящиеся на компьютере.

Альтернативным подходом было бы установить init.templateDir в вашей глобальной конфигурации git, устраняя необходимость в поиске существующего временного каталога. , Это, однако, заставляет вас поддерживать все - если в будущем какая-то фундаментальная часть этой структуры изменится, вам нужно будет поддерживать и обновлять свою копию.

Плюсы:

  • Конфигурирует хуки для репо, что означает, что вы можете продолжать использовать другие хуки для репо, если хотите

Минусы:

  • Влияет только на новые (инициализированные клонированные и ) репо; существующие репозитории не будут знать о новых добавлениях в ваш каталог шаблонов
  • Потенциально хрупкие для настройки из-за необходимости определить git место установки пользователя (или полностью поддерживать ваш собственный каталог шаблонов)

Для обоих вариантов вам необходимо выяснить, как часто они запускаются, чтобы убедиться, что ваши хуки обновляются. D Вы можете запускать их через регулярные промежутки времени или просто добавить pu sh на все клиентские машины, когда вы вносите изменения - все зависит от вашего административного инструментария

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

...