Версия ПО+ GIT

[pokk 0]

Добрый день, на писал на C# скрипт который от текущее время преобразует строку, и записываем массивом в файл, а этот файл подцепляю к проекту, и из массива вывожу на дисплей. Потом по дате можно поискать в логах GIT и найти комитет(нужный исходник), но это как-то не очень, было бы круче если тэг текушей ветки сразу бы заносился в массив, ну или что нибудь из GIT что бы можно было быстро и легко найти исходник(версию), зашитой программы.

Что можно в GIT использовать в качестве идентификатора?

Хотел ТЭГ, но

1) не нашел как узнать тэг текущей ветки

2) его надо в ручную инкрементировать =(

[andrew_b 0]

git describe?

[richie 0]

0xFF:

После того, как по сгенерированному файлу собрана версия, какая она будет после её занесения в систему контроля версий?

[arhiv6 0]

Можно завести отдельный фал, в котором лежит версия проекта. И написать два хука:

.git/hooks/pre-commit в котором автоматически перед коммитом делается инкремент версии в этом файле и делается git add этого фала

.git/hooks/post-commit в котором автоматически после коммита делается чтение этой версии и она записывается в тег через git tag -a

 

[kolobok0 0]

Можно завести..

 

+5 копеек

- добавить вэб морду для гита

- из CI системы можно сделать выбор необходимой версии и сборку в ручном режиме (автомат при этом так-же работает от пуша)

- ссылки из системы тасков в гит с записью в комментарии сообщения из коммитов (кто, что, референс в гит, версия, репозиторий и т.п.)

 

и т.д..

 

(круглый)

 

[pokk 0]

arhiv6, благодарю, надо будет разобраться в хуках.

kolobok0, Спасибо за CI, не знал что есть такое, какая самая простая?

Edited May 4, 2018 by pokk

[kolobok0 0]

...Спасибо за CI, не знал что есть такое, какая самая простая?

 

тут на цвет и вкус.

но лично сам больше сталкиваюсь с Jenkins

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

 

И ышо

5 копеек

Если вектор разработки в сторону вэбовских дел, то рекомендую глянуть технологии микросервисов, docker-container ну и управлялку под эти дела - rancher.

Последний так-же рулится из джэнкинса. Так-же из джэнкинса можно собирать контейнеры, регистрировать их (как пример) в локальном реестре и оттуда грузиться либо на рабочие станции либо в rancher.

 

 

с уважением

(круглый)

ЗЫ

Теоретически в контейнеры можно загонять усё чё не лень(тот же самый Jenkins). Но бОльший профит можно ожидать только от микросервисной технологии.

Edited May 4, 2018 by kolobok0

[pokk 0]

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

1. Включалась сборка HTML страницы (GULP)
2. Включалась утилита конвертации страницы в массив  (.exe)
3. создавалась версия ПО (инкремент+ HSA1 комита)
4. компиляция hex файл
5. Копирование полученный файл в папку HEX с новым именем версии ПО
6. Соединение  Hex файл c Hex файлом BootloAder
7. Создание временного файла hex файл с добавления серийного номера

Половину уже сделал на скриптах python, только встал вопрос как это все запускать ?  Сейчас пока сделал  что большая часть запускается при Merge в релизную версию. Но кажется мне такой подход не совсем корректным. 

Как это все сконфигурировать нормально ? В одних проекта некоторые шаги не нужны,в других нужны.  И как это сделать универсально что бы легко можно было перенести в новый проект. 

 

[kolobok0 0]

On 6/18/2019 at 7:37 AM, pokk said:

...на скриптах python, ...как это все запускать ? ...при Merge в релизную..Как ..сконфигурировать нормально ? ...как .сделать универсально ..перенести в новый проект. 

 

Тут ещё пол копейки.
Есть подход гитлаба (халява при поднятии своего, для мелких проектов - самое то) ну или заюзать вэб сервис от поставщика.
Так вот гитлаб может отрабатывать pipeline скрипт которых настраивается как yaml файл лежащий прямо в репе (или даже группа файлов). При этом перенос очень прост - меняется именно этот файл при переносе в другую репу.
Пайпа отрабатывается в ранерах гитлаба. По уму это разные тачки и ранеров может быть много. В пайпе можно делать параллельные и последовательные зависимости, ловить разные глаголы(не только мёрдж реквест), есть связи с мессэнджэрами, почтой, различными зоопарками. Немного глючноват, но терпимо.
На пайпах можно вызывать отработку любых докер контейнеров. А что внутри них вы отрабатываете - фигня вопрос. Хоть баши, хоть питоны, хоть пых-пыхи и т.д. и т.п..

Можно собирать артифакты которые легко переносятся между ранерами автоматом (один билдовка например, а второй крутиться на таргет машине. направили на развёртывание в таргет машину - тут же раскатали в продакшен)...

как то так
(круглый)
ЗЫ
Гит флоу вытекает из ворк-флоу. Обычно на бранчах работа быстрая, без изменений исходников. Например простановка тэгов. Причём имя генерируется с указанием имени бранча и уникального счётчика(привет кастом атрибутам). Выставляем тэг. На данный тэг можно ссылаться внешней автоматикой для дальнейшей сборки-CI. На мёрдже реквесте(точнее при его подготовке) идёт проверка исходников = билдовка, прогон тестов, наращивание версии (если пушим в мастер или релиз), коммит изменений, выставление тэга.
Можно прерывать пайпу и выходить на дальнейшее ручное проталкивание. Либо от настроек на проекте выставленные внешней автоматикой мы идём по нужным настройкам - например собирать ли, куда выкладывать, куда раскатывать и т.д. и т.п...

Edited July 25, 2019 by kolobok0