Дублирование перехватчиков git-клиента на стороне сервера - PullRequest
Новая
       10

Дублирование перехватчиков git-клиента на стороне сервера

0 голосов
/ 17 января 2019

Я определил хук после фиксации в .git/hooks, который я также хочу выполнить на стороне сервера ( Gitlab.com в моем случае).

Справочная информация: IЯ использую gitinfo2 вместе с ловушкой post-commit в проекте LaTeX для цитирования информации о последнем теге git в pdf.Это хорошо работает на моем компьютере, но не работает, когда я отправляю репо в Gitlab.

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

Package gitinfo2 Warning: I can't find the file '.git/gitHeadInfo.gin'.
(gitinfo2)                All git metadata has been set to '(None)'.

Из того, что я читал в Интернете до сих пор, клиентские git-хуки не выполняются на сервере - но почему бы и нет?В такой ситуации я хотел бы, чтобы ловушка выполнялась как на клиенте, так и на сервере.

Итак, в общем, я хочу, чтобы последовательность событий была такой:

  1. Я делаю фиксацию из файла .tex.
  2. Я отправляю коммит в Gitlab.
  3. Как только он попадает в Gitlab, выполняется ловушка git, приводящая к созданию файла с именем gitHeadInfo.gin.в папке .git.
  4. Латексный документ создается с использованием Gitlab CI, а пакет gitinfo помогает извлечь информацию о версии git из gitHeadInfo.gin.
  5. PDF развернутto Gitlab Pages .

У меня все работает, кроме шага 3. Итак, мой текущий обходной путь - это также создать pdf на моем компьютере и зафиксировать его, а не полагаясь на негона Gitlab CI.

Содержимое крючка git: 

#!/bin/sh
# Copyright 2015 Brent Longborough
# Part of gitinfo2 package Version 2
# Release 2.0.7 2015-11-22
# Please read gitinfo2.pdf for licencing and other details
# -----------------------------------------------------
# Post-{commit,checkout,merge} hook for the gitinfo2 package
#
# Get the first tag found in the history from the current HEAD
FIRSTTAG=$(git describe --tags --always --dirty='-*' 2>/dev/null)
# Get the first tag in history that looks like a Release
RELTAG=$(git describe --tags --long --always --dirty='-*' --match '[0-9]*.*' 2>/dev/null)
# Hoover up the metadata
git --no-pager log -1 --date=short --decorate=short \
    --pretty=format:"\usepackage[%
        shash={%h},
        lhash={%H},
        authname={%an},
        authemail={%ae},
        authsdate={%ad},
        authidate={%ai},
        authudate={%at},
        commname={%cn},
        commemail={%ce},
        commsdate={%cd},
        commidate={%ci},
        commudate={%ct},
        refnames={%d},
        firsttagdescribe={$FIRSTTAG},
        reltag={$RELTAG}
    ]{gitexinfo}" HEAD > .git/gitHeadInfo.gin

Ответы [ 2 ]

0 голосов
/ 13 марта 2019

Вот решение, которое работает для меня.Это требует от вас выполнения двух коротких команд один раз в любой копии репо.

В любой копии вашего репо выполните следующие действия:

  1. Скопируйте папку .git / hooksи / или любые скрипты хуков, которые вы хотите использовать для .githooks.Конечно, вы можете выбрать другое имя папки, чем .githooks.В частности, в верхней папке вашего репо используйте

    $ cp -a .git / hooks .githooks

  2. Добавить .githooks в репо

    $ git add .githooks

    $ git commit -m 'добавлен каталог .githooks'

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

В каждой локальной копии репо вам нужно будет

  1. Изменить конфигурацию локального репо, чтобы использовать .githooks вместо .git /hooks

    $ git config --local core.hooksPath .githooks

  2. На этом этапе локальное хранилище готово начать создавать файл .git / gitHeadInfo, но выигралоеще не сделали.Либо
    1. Сделать коммит
    2. Выполнить один из хуков gitinfo2 (которые в конце концов являются скриптами) вручную.Например,

      $ .githooks / post-commit

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

клиентские git-хуки не выполняются на сервере - но почему бы и нет?

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

Если вам действительно необходимо создать новый контент на стороне сервера (особенно тот, который не имеет прямого контроля, например GitLab.com), вам потребуется:

  • либо для активации какой-либо ловушки на стороне сервера, которая на данный момент доступна только на GitHub, с действиями GitHub .
  • или настройте прослушиватель GitLab webhook : этот webhook будет вызывать ( каждое push-событие ) ваш прослушиватель, который, в свою очередь, может получить новейшую историю, внести любые необходимые изменения , создайте новый коммит и нажмите назад.
...