Добавляем в Конвертацию данных 2.1 средства для работы с GIT

 Начав пользоваться GitRules мы столкнулись с ошибкой, связанной с длиной полного пути к файлам. Windows имеет ограничения даже в десятой версии. Попробовав разные способы обойти проблему остановились на «прозрачном» для пользователя использовании команды subst. Перед использованием GitRules мы просто монтируем папку как виртуальный диск.

Функция ПолучитьКороткийПутьКПапкеСПравиламиВГИТ(ПутьКПапкеСПравиламиВГИТ,ВыводитьЛогГит)
	Буквы = новый массив;
	Буквы.Добавить("G");Буквы.Добавить("H");Буквы.Добавить("I");Буквы.Добавить("J");Буквы.Добавить("K");
	Буквы.Добавить("L");Буквы.Добавить("M");Буквы.Добавить("N");Буквы.Добавить("O");Буквы.Добавить("P");
	Буквы.Добавить("Q");Буквы.Добавить("R");Буквы.Добавить("S");Буквы.Добавить("T");Буквы.Добавить("U");
	Буквы.Добавить("V");Буквы.Добавить("W");Буквы.Добавить("X");Буквы.Добавить("Y");Буквы.Добавить("Z");
	
	ПсевдонимНазначен = Ложь;
	
	Для каждого Буква Из Буквы Цикл
		Диск = новый файл(Буква+":\");
		Если НЕ Диск.Существует() Тогда
			СтрокаЗапуска = "subst "+Буква+": "+ """"+ПутьКПапкеСПравиламиВГИТ+"""";
			ЗапуститьПриложение(СтрокаЗапуска,,Истина);
			
			Если Диск.Существует() Тогда 
				СообщитьПользователю(Ложь,ВыводитьЛогГит,СтрокаЗапуска);
				ПсевдонимНазначен = Истина;
				Прервать; //subst сработал выходим и передаём букву
			КонецЕсли; 
		КонецЕсли; 
	КонецЦикла; 
	
	Если ПсевдонимНазначен Тогда
		Возврат Буква;
	Иначе
		СообщитьПользователю(Истина,ВыводитьЛогГит,"не удалось применить команду subst!");
		Возврат Неопределено;
	КонецЕсли;
	
КонецФункции

//Фрагмент вызова
БукваДиска = ПолучитьКороткийПутьКПапкеСПравиламиВГИТ(ИмяКаталога,ВыводитьЛогГит);
Если БукваДиска<>Неопределено Тогда
	СтрокаЗапуска = "gitrules.bat e """+ИмяФайлаПравил+""" "+БукваДиска+":\";
	СообщениеПриОшибке = "Что то пошло не так при выгрузке в GIT!";
	ЗапуститьВнешнееПриложение(СтрокаЗапуска,ИмяКаталога,Истина,ВыводитьЛогГит,КодировкаТекста.OEM,СообщениеПриОшибке);
	СообщитьПользователю(Ложь,ВыводитьЛогГит,"subst /D "+БукваДиска+":");
	Попытка
		ЗапуститьПриложение("subst /D "+БукваДиска+":",,Истина,);//освобождаем букву диска
	Исключение
				//не важно удалось или нет, в крайнем случае при перезагрузке пропадёт
	КонецПопытки;
КонецЕсли;

Конвертация вызывает консольные команды GIT и было некоторое неудобство, так как мы не видели в КД как отработали команды, были ли ошибки. Эту проблему решили, перенаправив вывод во временный файл, а затем считывая текст из него.

Функция ЗапуститьВнешнееПриложение(СтрокаЗапуска,ТекущаяДиректория,ОжидатьВыполнения,
                                   ВыводитьЛогГит,КодировкаТекстаВЛоге,СообщениеПриОшибке) 
	
		флРаботаБезОшибок = Истина;
	
		Попытка
			ЗапуститьПриложение("cmd /C cd "+ТекущаяДиректория+"\  && "+СтрокаЗапуска
                        +" 1>"""+ПолучитьИмяЛогФайла()+""" 2>&1",ТекущаяДиректория,ОжидатьВыполнения);
			СообщитьПользователю(Ложь,ВыводитьЛогГит,СтрокаЗапуска);
		Исключение
			флРаботаБезОшибок = Ложь;
			СообщитьПользователю(Истина,ВыводитьЛогГит,СообщениеПриОшибке);
		КонецПопытки;
		
		ВывестиВнешнийЛог(ВыводитьЛогГит,КодировкаТекстаВЛоге);
		
		Возврат флРаботаБезОшибок;
		
КонецФункции

Процедура ВывестиВнешнийЛог(ВыводитьЛогГит,КодировкаТекстаВЛоге)
	
	ИмяЛогФайла = ПолучитьИмяЛогФайла();
	ЛогФайл = новый Файл(ИмяЛогФайла);
	
	Если ЛогФайл.Существует() Тогда
		
		ПрочитанныйТекст = Новый ЧтениеТекста(ИмяЛогФайла,КодировкаТекстаВЛоге);
		
		СтрокаТекстовогоФайла = ПрочитанныйТекст.ПрочитатьСтроку();
		СообщитьПользователю(Ложь,ВыводитьЛогГит,СтрокаТекстовогоФайла);
		Пока СтрокаТекстовогоФайла <> Неопределено Цикл
			СтрокаТекстовогоФайла = ПрочитанныйТекст.ПрочитатьСтроку();
			СообщитьПользователю(Ложь,ВыводитьЛогГит,СтрокаТекстовогоФайла);
		КонецЦикла;
		
		ПрочитанныйТекст.Закрыть();
		
		Попытка
			УдалитьФайлы(ИмяЛогФайла);
		Исключение
			//Сообщить(ОписаниеОшибки());
		КонецПопытки;
	КонецЕсли; 	
	
КонецПроцедуры

Функция ПолучитьИмяЛогФайла() Экспорт
	ИмяЛогФайла = КаталогВременныхФайлов() +
	 СокрЛП(ПараметрыСеанса.ТекущийПользователь.Код) + "GitLog.txt";

	Возврат ИмяЛогФайла;

КонецФункции

Следующая проблема всплыла после переезда на наш локальный GitLab сервер. Наши админы настроили нам доменную авторизацию. Хранить доменные пароли в КД – не лучший вариант. Пришлось реализовать подключение через SSH ключи в Конвертации. При этом наткнулись на неприятный «сюрприз» при первом подключении - система выдает запрос пользователю, что сертификат новый и предлагает внести его в список известных хостов (то бишь сделать запись в файл ~\.ssh\known_hosts) 

Перехватить этот вопрос и послать автоматический ответ не удалось. Обойти это можно двумя путями. Либо в настройках указать отказ от проверки ключей, это не очень секьюрно, но в локальной сети приемлемо. Либо можно самим внести IP адрес в файле  known_hosts, этот способ лучше, но тогда адрес сервера GitLab не должен меняться. Мы выбрали второй вариант. Он описан в инструкции.

Оглавление

Установка необходимого софта 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 с помощью флагов:

1. Выгрузить в GIT – сработает плагин GitRules и файлы будут сохранены в локальную папку GIT

2. Сделать коммит – после выгрузки файлов они будут проиндексированы и «зафиксированы» в GIT

3. Сделать 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 с помощью флагов:

4. Выгрузить в GIT – сработает плагин GitRules и файлы будут сохранены в локальную папку GIT

5. Сделать коммит – после выгрузки файлов они будут проиндексированы и «зафиксированы» в GIT

6. Сделать push – последовательно сработает GitRules, коммит и отправка на удаленное хранилище GitLab

Флаг «Выводить лог» позволяет перехватить и увидеть сообщения, которые выдавали консольные команды git при выполнении.

Запрос на слияние в GitLab

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

Выгрузку правил можно делать сколько угодно раз. По завершении работ, делаем финальную выгрузку с установленным флагом «Сделать push». Затем заходим на сервер GitLab и отправляем запрос на слияние для нашей ветки:

Так как все значимые изменения мы выгружаем на удалённый репозиторий, то начиная работу над новым нарядом мы можем использовать локальную папку повторно, предварительно очистив её (не забудьте удалить скрытую папку .git внутри папки репозитория). Впрочем вы можете выбрать другую структуру, например для каждого наряда создавать свою папку с локальным репозиторием («старые» при этом можно архивировать, чтобы занимали меньше места).