Оглавление
Установка необходимого софта 2
Генерация ключа SSH и добавление открытой части в GitLab 2
Устанавливаем глобальные настройки GIT 3
Создаём новый проект в gitlab и загружаем в него правила обмена 3
Создаем проект в GitLab 3
Настройка подключения к GitLab в Конвертации данных 5
Сохранение правил обмена в GIT, commit, push 7
Доработка существующих в GitLab правил 8
Настройка подключения к GitLab в Конвертации данных 8
Сохранение правил обмена в GIT, commit, push 11
Запрос на слияние в GitLab 12
Установка необходимого софта
Инструкцию даю максимально коротко, подробно все описано в статье Олега Тымко (//infostart.ru/1c/articles/845576/). Единственный нюанс – не нужно устанавливать GitRules в качестве хука. То есть команду gitrules install не выполняем. Связано это с тем, что GitRules каждый раз пытается раскладывать все файлы правил, расположенные в папке. Если правил много – процесс долгий. Поэтому команды раскладывания на исходники и сборки подает сама конвертация (только для сохраняемых правил).
Сначала устанавливаем менеджер пакетов Chocolatey.
Далее, устанавливаем Git:
choco install git
Устанавливаем OneScript:
choco install onescript.cli -Source https://myget.org/F/onescript -y
Наконец, устанавливаем библиотеку Gitrules
opm install gitrules
P.S. При выполнении команды у пользователя должны быть права чтения/записи на каталог, в котором установлен Onescript.
P.P.S. Также нам понадобится конфигурация «Конвертация данных 2.1.8.2», её можно скачать с ИТС.
Генерация ключа SSH и добавление открытой части в GitLab
Если вы планируете использовать для доступа в GitLab логин и пароль, можете пропустить этот шаг.
Для генерации SSH ключа открываем git bash (в проводнике ПКМ) И набираем команду :
ssh-keygen -t ed25519 –C ВашЛогин@ВашДомен
Далее на все вопросы просто нажимаем Enter.
Ключ мы сгенерировали, теперь добавляем сервер gitlab в известные хосты:
ssh-keyscan gitlab.ВашДомен >> ~/.ssh/known_hosts
Получим в папке с профилем папку .ssh и в ней три файла:
Далее, открываем в блокноте файл с расширением pub – это открытая часть ключа. Копируем в буфер обмена и вставляем его в поле в настройках сервера GitLab
После вставки содержимого файла в поле «Заголовок» будет проставлен ваш адрес эл. Почты. Нажмите кнопку «Добавить ключ». На этом процедура добавления ключа закончена.
Если вы подключаетесь к GitLab с нескольких компьютеров, то можно просто скопировать папку .ssh в свою папку профиля на других компьютерах, либо сгенерировать новые ключи и добавить их согласно этой инструкции.
Устанавливаем глобальные настройки GIT
Чтобы ваши коммиты содержали информацию о вас необходимо выполнить команды:
git config --global user.name "Иванов Иван"
git config --global user.email Ivanov@mail.ru
Выполняем их либо в командной строке, либо в git bash
Создаём новый проект в gitlab и загружаем в него правила обмена
Если правила обмена уже добавлены в GitLab и вам нужно их доработать, то переходите к пункту «Доработка существующих в GitLab правил».
Создаем проект в GitLab
Заходим на сайт https://gitlab.ВашДомен, если вы готовы использовать глобальный сервер, переходите по этому адресу: https://about.gitlab.com/free-trial/
Процедуру регистрации я пропущу, мануалов в сети много. После авторизации нужно добавить новый проект:
Далее, на странице проекта нужно создать файл с его описанием (кнопка readme) – это будет наш первый файл проекта.
Все готово для клонирования. Кнопка «Клонировать» позволяет узнать адрес для клонирования репозитория, если вы настроили SSH ключи, то выбирайте адрес «Клонировать с помощью SSH».
На данном этапе доступ к проекту будет только у владельца, чтобы добавить других сотрудников зайдите в настройки проекта:
Настройка подключения к GitLab в Конвертации данных
Не забудьте сначала установить обновление из CFU файла публикации, а также интегрировать изменения Станислава Ганиева (//infostart.ru/public/632457/) без них при каждой загрузке/выгрузке в исходниках будет меняться порядок (тяжело будет увидеть значимые изменения и частота конфликтов в GIT вырастет).
Для настройки подключения используется добавленный в конфигурацию справочник:
Если снять флаг «использовать SSH ключ», становятся доступны поля для ввода логина и пароля.
Путь к репозитарию можно узнать в GitLab, нажав кнопку «Клонировать».
Следующий шаг – клонирование репозитария и создание новой ветки.
Для этого открываем регистр сведений «Гит ветки пользователя» и создаем новую ветку:
Сначала включаем флаг «Начальная ветка», это даст возможность выбрать конвертацию и путь к папке с правилами.
В обычном режиме (когда мы хотим отредактировать уже существующие в GitLab правила) этот флаг не потребуется.
Обратите внимание на «путь к локальной папке ГИТ» - в эту папку будет клонирован репозиторий с GitLab.
В поле «Номер наряда» задаем название ветки. Рекомендую указывать там номер задачи (наряда) из вашего трекера задач.
Далее заполняем поля и жмем кнопку «Клонировать». Если все настроено правильно, мы получим на жестком диске вот такую картину:
Скрытая папка .git – служебная папка, созданная GIT. Теперь папка MyGIT «синхронизирована» с удаленным хранилищем GitLab. Пока у нас в хранилище единственный файл README.MD – это описание проекта, которое мы создали в GitLab.
Если мы не создадим этот файл, то рискуем получить ошибку при создании новых веток. Это связано с тем, что для пустого проекта нельзя переключать ветки, нужно сначала поместить что-то в ветку master.
Следующий шаг – нажимаем кнопку «Создать ветку». Конвертация пошлет команду в ГИТ на создание ветки 000001, переключится на неё и выгрузит в неё правила, разложенные на исходники при помощи GitRules.
Завершающий шаг – нажимаем кнопку «ОК», сведения о созданной ветке запишутся в регистр сведений. Они нам еще понадобятся, когда потребуется сохранить в ГИТ измененные правила.
Сохранение правил обмена в GIT, commit, push
На предыдущем шаге мы создали и зарегистрировали новую ветку в ГИТ. А также разложили правила из Конвертации на исходники и сохранили их в локальную ГИТ папку. Однако, пока наши файлы «не зафиксированы» в гит. И не отправлены в GitLab.
Для того, чтобы это сделать воспользуемся стандартным окном сохранения правил обмена. Внизу появилась панель для работы с ГИТ. Всё, что нам сейчас нужно, выбрать нашу ветку ГИТ. Пути будут заполнены из регистра сведений.
Не забудьте заполнить комментарий, он будет сохранен при коммите. Кнопка Git status позволяет проверить, на какой ветке мы находимся (сам по себе выбор ветки из регистра сведений ветку в GIT не переключает), а также дает нам дополнительную информацию о состоянии наших файлов. Кнопка «Переключить GIT на ветку» делает попытку переключиться на выбранную ветку (не всегда это возможно автоматически, например если есть не закоммиченные изменения).
Непосредственно работа с GIT происходит при нажатии на кнопку «Сохранить». Вы управляете действиями в GIT с помощью флагов:
-
Выгрузить в GIT – сработает плагин GitRules и файлы будут сохранены в локальную папку GIT
-
Сделать коммит – после выгрузки файлов они будут проиндексированы и «зафиксированы» в GIT
-
Сделать push – последовательно сработает GitRules, коммит и отправка на удаленное хранилище GitLab
Флаг «Выводить лог» позволяет перехватить и увидеть сообщения, которые выдавали консольные команды git при выполнении.
Примечание: Список веток в конвертации фильтруется по пользователю и по конкретным правилам обмена. Когда работа с веткой завершена установите в регистре сведений флаг «Ветка закрыта»
Доработка существующих в GitLab правил
В этой главе рассмотрим ситуацию, когда мы подключаемся к уже существующему проекту gitlab, получаем правила и загружаем изменения обратно в GitLab.
Если правила обмена еще не добавлены в GitLab и вам нужно их выгрузить, то переходите к предыдущему пункту «Создаём новый проект в gitlab и загружаем в него правила обмена».
Сначала нужно узнать адрес удаленного репозитория, для этого нужно зайти на страницу нужного проекта в GitLab и нажать кнопку «Клонировать». Если вы настроили SSH ключи, то выбирайте адрес «Клонировать с помощью SSH».
Настройка подключения к GitLab в Конвертации данных
Не забудьте сначала установить обновление из CFU файла публикации, а также интегрировать изменения Станислава Ганиева (//infostart.ru/public/632457/) без них при каждой загрузке/выгрузке в исходниках будет меняться порядок (тяжело будет увидеть значимые изменения и частота конфликтов в GIT вырастет).
Для настройки подключения используется добавленный в конфигурацию справочник:
Если снять флаг «использовать SSH ключ», становятся доступны поля для ввода логина и пароля.
Следующий шаг – нужно открыть стандартный диалог загрузки правил обмена. В этом диалоге добавлена панель для работы с ГИТ.
Первое, что мы должны сделать – нажать кнопку регистрации новой ветки. В появившемся окне записи регистра сведений заполняем реквизиты, как показано на рисунке:
Обратите внимание на «путь к локальной папке ГИТ» - в эту папку будет клонирован репозиторий с GitLab.
В поле «Номер наряда» задаем название ветки. Рекомендую указывать там номер задачи (наряда) из вашего трекера задач.
Нажимаем кнопку «Клонировать» и затем нажимаем «ОК». Если все сделано правильно, то в локальной папке ГИТ будет вот такая картина:
В папке UT_BUH.xml лежат исходники правил обмена. Файл README.md содержит описание проекта GitLab. А скрытая папка .git – это служебная папка локального GIT.
После нажатия «ОК» мы вернулись в окно загрузки правил обмена, теперь нужно выбрать нашу (только что созданную) ветку:
Заполняем пути. Путь к папке с правилами в GIT – это «корневой» путь к нужным нам правилам, в этой папке лежит файл «ПравилаОбмена.xml».
Путь к собираемому файлу – это может быть временная папка, куда плагин GitRules сохранит уже готовый XML файл с правилами обмена.
Флаг «Выводить лог» позволит увидеть сообщения, которые выдают консольные команды git при выполнении.
Жмем кнопку «Собрать из GIT» - сработает плагин GitRules и создаст полный XML файл с правилами из исходников. При этом имя файла подставится автоматически.
Далее ставим галочку «Создать и привязать к ветке» - это позволит конвертации запомнить нужные пути, чтобы при выгрузке правил они подставились автоматически.
Завершающий этап - жмем кнопку «Загрузить». Правила обмена будут загружены в КД2, как обычно. Далее работа с ними ничем не отличается до момента выгрузки обратно в файл.
Сохранение правил обмена в GIT, commit, push
На предыдущем шаге мы создали и зарегистрировали новую ветку в ГИТ. А также собрали правила обмена из исходников и загрузили их в КД2. Внеся необходимые изменения мы можем, как обычно, выгружать правила в XML файл. Однако, пока наши файлы «не зафиксированы» в гит. И не отправлены в GitLab.
Для того, чтобы это сделать воспользуемся стандартным окном сохранения правил обмена. Внизу появилась панель для работы с ГИТ. Всё, что нам сейчас нужно, выбрать нашу ветку ГИТ. Пути будут заполнены из регистра сведений.
Не забудьте заполнить комментарий, он будет сохранен при коммите. Кнопка Git status позволяет проверить, на какой ветке мы находимся (сам по себе выбор ветки из регистра сведений ветку в GIT не переключает), а также дает нам дополнительную информацию о состоянии наших файлов. Кнопка «Переключить GIT на ветку» делает попытку переключиться на выбранную ветку (не всегда это возможно автоматически, например если есть не закоммиченные изменения).
Непосредственно работа с GIT происходит при нажатии на кнопку «Сохранить». Вы управляете действиями в GIT с помощью флагов:
-
Выгрузить в GIT – сработает плагин GitRules и файлы будут сохранены в локальную папку GIT
-
Сделать коммит – после выгрузки файлов они будут проиндексированы и «зафиксированы» в GIT
-
Сделать push – последовательно сработает GitRules, коммит и отправка на удаленное хранилище GitLab
Флаг «Выводить лог» позволяет перехватить и увидеть сообщения, которые выдавали консольные команды git при выполнении.
Запрос на слияние в GitLab
Запрос на слияние необходим, чтобы изменения правил из нашей ветки попали в главную ветку master.
Выгрузку правил можно делать сколько угодно раз. По завершении работ, делаем финальную выгрузку с установленным флагом «Сделать push». Затем заходим на сервер GitLab и отправляем запрос на слияние для нашей ветки:
Так как все значимые изменения мы выгружаем на удалённый репозиторий, то начиная работу над новым нарядом мы можем использовать локальную папку повторно, предварительно очистив её (не забудьте удалить скрытую папку .git внутри папки репозитория). Впрочем вы можете выбрать другую структуру, например для каждого наряда создавать свою папку с локальным репозиторием («старые» при этом можно архивировать, чтобы занимали меньше места).
