2016-07-05 4 views
2

Я работаю над улучшением нашей текущей системы сборки для очень большого проекта .Net. Чтобы выразить это в контексте - в этом проекте имеется 178 решений Visual Studio и более 800 файлов csproj.Gitlab-CI: Trigger build только при обновлении конкретных папок

В настоящее время мы используем TeamCity, но с количеством команд у нас это стало огромным беспорядком, и его очень сложно поддерживать. В какой-то момент мы перешли в Gitlab (до моего приезда), и я пытаюсь получить работоспособное решение с использованием Gitlab-CI.

Мне удалось создать, Test и Package, каждый компонент с использованием Gitlab-CI, но это не очень хорошо, поскольку все делается в 1 Job. Мы решили сделать это как сейчас, так как очень сложно (и медленно) управлять всеми артефактами в Gitlab-CI, если мы создадим отдельные компоненты. Но я оставлю это для другого вопроса SO ... ;-)

Мой вопрос сегодня в том, как я могу настроить свой файл .gitlab-ci.yml только для выполнения задания, если бы были внесены изменения в эту конкретную папку?

Рассмотрим это (упрощенный) дерево каталогов: . ├── Build ├── Config ├── Core ├── Database ├── Services └── Websites

Если изменения объединяются, чтобы мастера, которые влияют на сердечник или Config, то все дерево должно быть построено и испытано, так как все зависит от этих компонентов. Однако если изменения внесены в Службы, нет необходимости создавать и тестировать что-либо, кроме Сервисов.

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

+0

использовать специализированные отделения для компонентов ли? – Martin

+0

@ mgansler Я предполагаю, что вы имеете в виду ветви гита? На этом этапе нет - все сидит в 1 хранилище. Обычно команда отказывается от основного репо, а затем снова объединяет свои изменения. –

+0

Да, я имел в виду ветви гита. Если вы представите выделенную ветку для каждого компонента, вы можете использовать gitlab-ci 'only': http://docs.gitlab.com/ce/ci/yaml/README.html#only-and-except – Martin

ответ

1

Просто наткнулся на ваш вопрос.

Это просто идея, но внутри сценария сборки вы можете сравнить git log -n 1 --pretty=format:%h Database с git log -n 1 --pretty=format:%h и только перестроить, если это отличается.

git log -n 1 покажет вам некоторую информацию о последнем фиксации для вашего репо или конкретного каталога/файла.

commit <full sha hash of current commit> 
Author: Author Name <[email protected]> 
Date: Fri Mar 10 11:08:42 2017 +0100 

    commit message 

в то время как --pretty=format:%h будет только выход укороченного хэш

git log -n 1 --pretty=format:%h 
1234567 

git log -n 1 --pretty=format:%h Database 
7654321