GitSync 3.0. Шпаргалка по использованию

25.11.2019 10 Comments

Git (GitHub, GitLab, BitBucket), Разработка

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

Лирическое вступление

На днях довелось заниматься настройкой синхронизации Хранилища с репозиторием Git на новом проекте. Делал я это не первый раз, наработки кое-какие уже есть, поэтому каких-то больших временных затрат не предполагалось. Всё начиналось стандартно: установка oscript, обновление всех пакетов менеджером opm, инсталляция gitsync. И на этом шаге возник нюанс, имя которому "gitsync 3.0". Как оказалось, уже полгода как он вышел в релиз и заменил собой прежнюю версию 2.4.3. 

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

Как строится новая строка вызова, удалось понять достаточно быстро. А вот разбирательство с плагинами, которые мне требовалось задействовать, затянулось на несколько часов.

Сначала в ход был пущен всеми любимый метод научного тыка. Пробовал подставлять параметры (те, что раньше применял в 2.4.3) и так и этак, чувствуя себя при этом героем басни "Мартышка и очки". Следующим пошел в ход метод "Если ничто не помогает, попробуй прочитать Инструкцию", но и он не принес желаемых результатов. После этого последовал гуглинг, оказавшийся столь же безрезультатным. Увенчалось всё погружением в исходники.

Как обычно, всё оказалось очень просто. Но… не очевидно. И документация (на текущий момент) не очень помогает. Потому и родилась сия шпаргалка.

Новшества GitSync 3.0

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

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

Второе — теперь возможно указать информационную базу, используемую в качестве временной, для загрузки Конфигурации из Хранилища и выгрузки в файлы. Ранее для этого каждый раз создавалась временная файловая база. Проблемой это становилось, если на сервере, где происходит работа, нет возможности получить клиентскую лицензию. Например, клиентские лицензии выдает сервер приложений 1С. 

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

Командная строка

Строка запуска приложения прежней версии выглядела следующим образом:

>gitsync export D:1c
eposproject_rep ./sources/config -tempdir D:	empfiles -v8version 8.3.10.2561

Сначала указывалась Команда (в примере — export), далее шли позиционные параметры (в примере — путь к Хранилищу и к репозиторию),  затем все опциональные параметры.

В новой версии кроме изменения имени самой команды (export -> sync), меняется и необходимый порядок указания параметров.
Выведем справку по приложению gitsync:

 

 >gitsync —help

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

Например, для команды sync:

 

 >gitsync sync —help

Здесь видим, что опции команды переместились и теперь располагаются перед позиционными параметрами.

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

>gitsync --tempdir Z:	empfilesgitsync --v8version 8.3.14.1630 sync --storage-user gitbot tcp://test_1c_app/uh_main_rep Z:git_reposuh_mainconfig

Плагины

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

 

 Список входящих в поставку плагинов:

  • increment — обеспечивает инкрементальную выгрузку конфигурации в исходники
  • sync-remote — добавляет функциональность синхронизации с удаленным репозиторием git (команды git pull и git push)
  • limit — добавляет возможность ограничения на минимальный, максимальный номер версии хранилища, а так же на лимит на количество выгружаемых версий за один запуск
  • check-authors — добавляет функциональность проверки автора версии в хранилище на наличие соответствия в файле AUTHORS
  • check-comments — добавляет функциональность проверки на заполненность комментариев в хранилище
  • smart-tags — добавляет функциональность автоматической расстановки меток в git (команда git tag) при изменении версии конфигурации
  • unpackForm — добавляет функциональность распаковки обычных форм на исходники
  • tool1CD — заменяет использование штатных механизмов 1С на приложение tool1CD при синхронизации
  • disable-support — снимает конфигурацию с поддержки перед выгрузкой в исходники

После установки gitsync поставляемые плагины содержатся в файле "embedded_pluginsgitsync-plugins-1.0.5.ospx" в заархивированном виде.

Для того, чтобы ими воспользоваться, первым делом нужно инициализировать предустановленные плагины, выполнив команду:

>gitsync plugins init

При инициализации плагины будут распакованы в каталог данных приложения — %localappdata%gitsyncplugins

Но этого еще недостаточно.
Если выполнить команду, выводящую список всех установленных плагинов, увидим, что все плагины выключены:

 

 >gitsync plugins list -a

Теперь требуется активировать нужные плагины.
В моем примере, необходимые плагины — limit и check-comments:

C:>gitsync plugins enable limit
Включен плагин: limit

C:>gitsync plugins enable check-comments
Включен плагин: check-comments

Теперь команда вывода списка подключенных плагинов покажет что плагины limit и check-comments включены:

 

 >gitsync plugins list

 C:>gitsync plugins list
Каталог плагинов: <C:Users1c_dev2AppDataLocalgitsyncplugins>
Список плагинов:
 [on] [1.0.5] — limit — Плагин добавляет возможность ограничения на минимальный, максимальный номер версии хранилища, а так же на лимит на количество выгружаемых версий за один запуск
 [on] [1.0.5] — check-comments — Плагин добавляет функциональность проверки комментариев в хранилище

Промежуточное "Ура!". Осталось выяснить, каким же образом эти плагины теперь использовать. Какие параметры? В каком месте нужно указывать? Где смотреть справку по ним?

Попытки получить справку по плагину возвращают ошибку:

 

 >gitsync plugins limit —help

 C:>gitsync plugins limit —help
КРИТИЧНАЯОШИБКА — Ошибка чтения параметров команды
Команда: plugins, p
 Управление плагинами gitsync 

Указанная в документации команда с примерами возвращает пустой результат, т.к. на текущий момент не реализована.

>gitsync usage plugins

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

 

 >gitsync sync —help

 C:>gitsync sync —help
Команда: sync, s
 Выполняет синхронизацию хранилища 1С с git-репозиторием

Строка запуска: gitsync sync [ОПЦИИ] PATH [WORKDIR]

Аргументы:
  PATH          Путь к хранилищу конфигурации 1С. (env $GITSYNC_STORAGE_PATH)
  WORKDIR       Каталог исходников внутри локальной копии git-репозитория. (env $GITSYNC_WORKDIR)

Опции:
  -u, —storage-user            пользователь хранилища конфигурации (env $GITSYNC_STORAGE_USER) (по умолчанию Администратор)
  -p, —storage-pwd             пароль пользователя хранилища конфигурации (env $GITSYNC_STORAGE_PASSWORD, $GITSYNC_STORAGE_PWD)
  -e, —ext, —extension        имя расширения для работы с хранилищем расширения (env $GITSYNC_EXTENSION)
  -l, —limit                   [*limit] выгрузить не более <Количества> версий от текущей выгруженной (env $GITSYNC_LIMIT) (по умолчанию 0)
      —minversion              [*limit] <номер> минимальной версии для выгрузки (по умолчанию 0)
      —maxversion              [*limit] <номер> максимальной версии для выгрузки (по умолчанию 0)
  -C, —error-comment           [*check-comments] флаг вызова ошибки при отсутствии текста комментари

Теперь видим, что по сравнению с первоначальным выводом этой команды, в результатах появились строки с указанием ключей плагинов limit и check-comments. И размещать их нужно вместе с опциональными параметрами команды, перед позиционными параметрами.

Таким образом, с учетом необходимых параметров плагинов, строка запуска будет выглядеть примерно так: 

>gitsync --tempdir Z:	empfilesgitsync --v8version 8.3.14.1630 sync --storage-user gitbot --limit 1 --error-comment tcp://test_1c_app/uh_main_rep Z:git_reposuh_mainconfig

Теперь всё работает так, как и требовалось. 

Эпилог

Надеюсь что кому-то моя заметка поможет сэкономить пару часов поисков и разбирательств с новым синтаксисом.

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

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

Related Posts

10 Comments

  1. awk

    А формат выгрузки EDT, 1С или какой еще?

    Reply ↓
  2. -vito-

    (1) Василий,

    GitSync выгружает файлы посредством Конфигуратора (как если бы Вы выполнили команду Конфигурация->Выгрузить конфигурацию в файлы…), соответственно, формат выгрузки 1С-ный.

    Что касается EDT, она по сути, тоже работает через Конфигуратор, запускаемый либо в пакетном режиме (при импорте конфигурации), либо в режиме ssh-сервера. Всё что делает с Конфигурацией EDT, это конвертация из 1C-ных XML в свой формат и обратно.

    Вся работа по сборке из исходников CF-файла, обновление БД, по-прежнему выполняется Конфигуратором. Вы можете увидеть его среди процессов в Диспетчере задач или ProcessExplorer-е.

    У EDT есть интерфейс командной строки, что позволяет, среди прочего, конвертировать «1С-ную» XML-выгрузку Конфигуратора в формат EDT и обратно.

    Таким образом, если Вам требуется выгрузка в формате EDT, то, получив выгрузку Хранилища, можно следующим шагом сконвертировать её в EDT примерно такой командой:

    >ring edt workspace import —configuration-files d:/XML-1/ —project D:/project-1 —workspace-location D:/workspace

    Подробнее в справке по EDT: Конвертация xml-выгрузки конфигурации в файловое представление EDT

    Уточнение. GitSync сразу выполнит коммит полученной XML-выгрузки в репозиторий Git. Полагаю, что для целей конвертации в формат EDT выгрузки из Хранилища, нужно либо немного доработать GitSync, либо сделать к нему соответствующий плагин, либо написать свой скрипт. Возможно, существует готовое решение, но я его не искал.

    Reply ↓
  3. awk

    (2) Спасибо. У меня несколько переписанный (а точнее, смотря на него, с нуля написанный) ГитКонвертер….

    Reply ↓
  4. Angel_19

    Т.е. для работы с Git использование хранилища необязательно, раз конфигурация выгружается посредством Конфигуратора?

    Reply ↓
  5. -vito-

    (4) Роман,

    для работы с Git использование Хранилища не обязательно. По сути, это две разных системы контроля версий. Одна — проприетарная от 1С, другая — от linux-сообщества.

    Вместо помещений в Хранилище, Вы можете каждый раз делать выгрузку в XML (инкрементальную, чтобы не выгружать всё) и коммитить в git-репозиторий выполнением команд в консоли, либо каким-либо git-клиентом.

    Как раз так и работают в EDT. Там лишь нет шага «выгрузка в файлы», т.к. EDT работает не с «черным ящиком» Конфигурации а с уже выгруженными файлами.

    В таком случае Вам не нужен GitSync. Он предназначен для того, чтобы синхронизировать с git-репозиторием «стандартную» разработку, при которой используется Хранилище.

    Reply ↓
  6. Angel_19

    (5)

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

    Reply ↓
  7. _LkMaksimka_

    Обнаружил небольшую особенность, GitSync будет выдавать сообщение 

    КРИТИЧНАЯОШИБКА — {Модуль C:Program FilesOneScriptlibgitsyncoscript_modulesv8storagesrcКлассыinternal
ipperКлассыПарсерОтчетаХранилища.os / Ошибка в строке: 177 / Преобразование к типу ‘Число’ не поддерживается}

    Если при помещении в хранилище 1С в комментарии указать «Версия: …..» из-за этого неправильно формируется таблица значений 

    ТаблицуВерсий

    в процедуре 

    Функция СформироватьТаблицуВерсий(Массив)
    Reply ↓
  8. -vito-

    (7) Максим,

    дело в том, что библиотека v8storage список коммитов получает с помощью отчета по версиям в формате mxl, получаемого запуском Конфигуратора в пакетном режиме с ключом /ConfigurationRepositoryReport.

    Далее полученный отчет парсится и вхождение строки «Версия:» является ключевым — после него ожидается номер версии. А у Вас получается, что этот текст стоит в комментарии.

    Если для Вас использование именно такой строки в комментариях является критичным, вероятно придется дорабатывать алгоритм парсинга.

    А если не критично — заменить на что-нибудь отличающееся, но имеющее тот же смысл, например «Номер версии:»

    Reply ↓
  9. _LkMaksimka_

    (8)Витaлий,

    Для меня это не критично, комментарий я поправил. Просто хотел поделится этой особенностью.

    Reply ↓
  10. leemuar

    (7) классная ошибка, здорово что нашли! Запишите задачу на исправление в гитхабе проекта: https://github.com/oscript-library/gitsync/issues

    Reply ↓

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *