Тип хука для исключения типов файлов из репозитория Git - PullRequest
0 голосов
/ 11 декабря 2018

Я пытаюсь написать git hook, который предотвратит отправку таких файлов, как .exe-файлы в репозитории.

Мы используем Gitlab для управления исходным кодом, и этот хук будет работать вместо Gitlab 'Правило push имен запрещенных файлов.

Мой вопрос: какой тип хука мне искать?

Я пошел по пути написания крюка предварительного получения.Это звучит правильно?

Спасибо,

Шон

Ответы [ 2 ]

0 голосов
/ 11 декабря 2018

На сервере у вас есть две опции, а именно: pre-receive и update hooks.(В этом конкретном случае я бы, вероятно, сам использовал хук обновления.)

Хук предварительного получения вызывается один раз, при этом стандартный ввод подключается к каналу, содержащему все предложенные эталонные обновления.Вы должны прочитать все строки stdin и использовать старый и новый хеш-идентификаторы и имена всех ссылок, чтобы решить, разрешено ли выполнение push whole , или push whole все обновления имени - должны быть отклонены все сразу.То есть, учитывая, что какой-то клиент запустил:

git push origin hash1:name1 hash2:name2 ... hashN:nameN

, так что есть N запросов на обновление на N строках stdin, ваш хук предварительного получения либопринимает все или отклоняет все.Чтобы принять все, выйдите со статусом ноль;запретить все, выйти с любым ненулевым статусом.Хорошей идеей будет напечатать причину для отказа, если вы выйдете из ненулевого значения, чтобы клиент понял, почему вы это сделали.

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

То есть, при одном и том же вызове клиента будет задействована ваша ловушка обновления N отдельно.Второй будет, например, иметь:

$1: refs/heads/name2
$2: the old hash ID (or the all-zeros "null hash")
$3: the new hash ID (or all-zeros)

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

О серверных хуках в целом

Ваши хуки получают, по ссылке, старый хэш-идентификатор ($old ниже), новый ($new) и полное имя ссылки: refs/heads/<em>name</em>, если ссылка является именем ветви, refs/tags/<em>name</em>, если это имя тега, refs/notes/<em>name</em> если это ссылка на заметки, и так далее.Хук обновления имеет более тонкую детализацию, но не может видеть предлагаемое обновление в целом.

Не более одного из $old или $new будет все нули.Если это так, ссылка должна быть создана - например, новая ветка или тег - или уничтожена.В противном случае это обновление на месте: ссылка в настоящее время указывает на хэш-идентификатор $old, а лицо, работающее с git push, предлагает изменить его так, чтобы оно указывало на хэш-идентификатор $new.

Эти крючки очень эффективны, но их сложно написать.В частности, если ссылка обновляется , довольно ясно, что делать: обновление добавит коммиты в диапазоне $old..$new, поэтому:

git rev-list $old..$new | while read rev; do
    # examine the files in $rev
done

достаточно, чтобы позволить вампроверить содержимое каждого предложенного нового коммита.(Некоторые коммиты могут быть удалены , и их можно найти, проверив $new..$old.)

Однако, если ссылка недавно созданная , $old будетбыть все нули.Невозможно точно сказать, какие ссылки были недавно введены исключительно этой конкретной ссылкой.Вы можете использовать этот трюк:

git rev-list $new --not --all

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

...--o--o--o   <-- master
            \
             A--B   <-- newbranch1
                 \
                  C   <-- newbranch2
                   \
                    D--E--F   <-- newbranch3

В отдельности, запрос на установку newbranch3 для указания коммита, чей ID хеша F выглядит как запрос на добавление всех шести коммитов (что это такое!), Но вы можете просмотреть это как запрос на добавление только трех коммитов после ветки, добавленной в противном случаеnewbranch2, например.Невозможно создать это представление в хуке обновления. возможно (но сложно) произвести его в хуке предварительного получения, поскольку он может сказать, что все три newbranch* имени являются новыми.

0 голосов
/ 11 декабря 2018

Лучший способ исключить файлы из проверки в системе контроля версий - через .gitignore

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

...