2016-11-24 4 views
-1

Недавно я понял, что процесс сборки моей организации не удался, если ваша ветка содержит / в имени филиала, потому что процесс сборки создает файл с именем файла <blah>_<branch_name>.type в папке say Корневая папка.Настроить git на ошибку при использовании определенных символов в имени филиала

например. Название филиала: DEV/someDev/someBranch

FileName: `<blah>_dev/someDev/someBranch.type` 

Поскольку название филиала содержит /, файл фактически будет создаваться на RootFolder\<blah>_dev\someDev\ с именем файла, someBranch.type. Теперь процесс, ожидающий файл в RootFolder, не находит файл, который приводит к сбою процесса сборки.

Итак, есть ли способ, которым я могу настроить git, чтобы вызвать ошибку, если имя ветви содержит некоторые незаконные символы?

ПРИМЕЧАНИЕ: В этом пункте я не могу изменить процесс сборки. Кроме того, я знаю, что есть несколько других способов назвать ветку: dev-someDev-someBranch, с помощью которой мы можем избежать удара этой сборки, но мне любопытно узнать, смогу ли я настроить git указанным выше способом.

+0

Обратная косая черта не является юридическим символом в имени филиала (или никакой ссылки). См. Правило № 10 https://www.kernel.org/pub/software/scm/git/docs/git-check-ref-format.html – torek

+0

@torek Извините за путаницу. Я имел в виду форвард-слэш. – unrealsoul007

ответ

2

Ну, вы не сказали нам где вы хотите имена филиалов, чтобы проверить против вашей политики — на машинах разработчиков или в хранилище они толкают или в хранилище на сервере сборки извлекает в (если eny) или где-то еще полностью.

Я думаю, что простейшая настройка точки для такой проверки - это хранилище, на которое разработчики нажимают свою работу.

Чтобы реализовать такое принудительное выполнение политики, вам необходимо написать и включить так называемый крюк в этом репозитории; в частности, крючок pre-receive.

Крючки - это скрипты (или любые другие исполняемые программы), которые Git вызывает при выполнении определенных действий в репозитории. См. git help hooks, чтобы прочитать обзор. Каждый крюк должен следовать определенному соглашению для работы с Git. Обычно перехватчики считывают данные, предоставленные Git, из их стандартного входного потока, ничего не записывают в свой стандартный выходной поток и не сигнализируют об успешном завершении (или «ОК, чтобы продолжить»), выйдя с кодом состояния 0 и сбоем (или «не в порядке продолжить»), выйдя из с ненулевым кодом выхода; в последнем случае они могут записать сообщение об ошибке в свой стандартный поток ошибок.

Крюк интереса, pre-receive роллов, как это:

pre-receive Этот хук вызывается мерзавец-прием-пакет на удаленное хранилище, которое происходит, когда мерзавец толчок делается на локальное хранилище , Перед тем, как начинать обновление ссылок в удаленном репозитории, вызывается крючок pre-receive. Его статус выхода определяет успех или неудачу обновления.

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

<old-value> SP <new-value> SP <ref-name> LF 

где <old-value> старое название объекта хранится в реф, <new-value> новое имя объекта для хранения в ref и <ref-name> - полное наименование ссылки. При создании новой ссылки <old-value> составлен 40.

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

Как стандартный выход, так и стандартный выход ошибки передаются на git send-pack на другом конце, поэтому вы можете просто эхо-сообщения для пользователя.

Таким образом, вы должны были бы написать программу крючков, которое считывает данные из стандартного входного потока, интерпретирует его как набор LF -разделенных линий, разбить каждый из трех полей, разделенных два SP (пробела) символов и проверьте третье поле —, которое будет именем филиала — не имеет недопустимых символов в соответствии с вашей политикой.

Если ваш крючок обнаруживает нарушение poilcy, он должен написать сообщение в свой стандартный поток ошибок и выйти с ненулевым кодом выхода. Это приведет к тому, что Git не обновит репозиторий данными, которые разработчик попытался вставить в него.

+1

Третье поле будет * reference * name. Это имя ветки тогда и только тогда, когда оно начинается с 'refs/heads /'. Если он начинается с 'refs/tags /', это имя тега; если он начинается с 'refs/notes /', это из 'git notes'. Тем не менее, это, как правило, правильный ответ, и я поддержал его :-) хотя обратная косая черта во всех ссылках запрещена, так что исходный вопрос имеет большую техническую проблему! – torek

+0

Спасибо за такой информативный ответ. Это именно тот уровень уместности и подробностей, которые я искал. – unrealsoul007

 Смежные вопросы

  • Нет связанных вопросов^_^