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

Я работаю над проектом A, и A зависит от быстро развивающегося проекта B (его основная ветвь).

Следовательно, B является подмодулем A, каждый раз, когда я строю A, B также перестраивается. Кроме того, каждый раз, когда у B появляется новый коммит, мне нужно построить B, а затем заново построить A. (К счастью, проекты достаточно малы, поэтому время компиляции не имеет значения).

Теперь вот в чем дело. Я хочу запустить новую сборку в Travis CI или других сервисах непрерывной интеграции, когда есть новая фиксация в проекте A или B.

Я только что попробовал Github и Travis CI. Фиксация в проекте B не вызовет сборку в проекте A. Есть ли простой способ запустить такую ​​непрерывную интеграцию?


git continuous-integration travis-ci
person Endle_Zhenbo    schedule 10.01.2016    source источник
comment
Я не уверен, что понимаю. Обычно с подмодулями ваш основной проект будет зависеть от конкретной версии подмодуля. Обновление в репозитории подмодуля не должно запускать сборку в основном репо до тех пор, пока зависимость основного репо не будет обновлена ​​до более новой ревизии, что в любом случае приведет к перестройке основного репо. Я что-то упускаю?   -  person Chris    schedule 10.01.2016
comment
@ Крис, спасибо. Я знаю, что лучше полагаться на ревизию. Но в этом случае проект B развивается очень быстро, не оставляя мне никаких доработок, и мне нужно идти в ногу с основной веткой. Такая ситуация не обычная, но действительно существует.   -  person Endle_Zhenbo    schedule 10.01.2016
comment
Итак, у вас есть подмодуль, отслеживающий ветку (т.е. созданный с использованием флага -b), и вы хотите запускать новую сборку для основного репозитория каждый раз, когда ветвь подмодуля обновляется?   -  person Chris    schedule 10.01.2016
comment
@ Крис, да, я хочу именно этого. Извините за мое выражение   -  person Endle_Zhenbo    schedule 10.01.2016

Ответы (2)


arrow_upward
7
arrow_downward

Фиксация в проекте B не вызовет сборку в проекте A

Этого и следовало ожидать, учитывая, что B понятия не имеет о существовании A.

Вам потребуется записать новое состояние B (новый gitlink, специальную запись в индексе) проекта A, выполнив:

cd /path/to/projectA
git submodule update --remote
git add .
git commit -m "Record new B SHA1 gitlink"
git push

git submodule update --remote обновит подмодуль B до последней фиксации ветки, записанной в файле A .gitmodules для B.
См. "git submodule tracking latest" и "подмодули Git: укажите ветку / тег"

Затем для А. будет запущена новая сборка Трэвиса.

Если вы хотите автоматизировать описанную выше последовательность, вам понадобится веб-перехватчик (GitHub) (или BitBucket) для projectB, и локальный слушатель, который при событии push в репо B, вызовет команды, упомянутые ранее в локальном репо проекта A.

person VonC    schedule 10.01.2016

arrow_upward
3
arrow_downward

Основываясь на вопросе @VonC, я решил эту проблему. Ссылка https://developer.github.com/webhooks/configuring/

  1. Я создал проект Monitor, в котором есть два подмодуля, проект A и B.
  2. Создать файл trigger.rb в Мониторе проекта

требуется "синатра"

post '/payload' do
  system("git submodule update --remote")
  system("git add .")
  system("git commit -m Record_new_change")
  system("git push")
  puts "Finished handling"
end
  1. Загрузите ngrok, запустите его на VPS или долго работающем коммуникаторе с ./ngrok http 4567. У вас может быть ссылка типа http://7e9ea9dc.ngrok.io
  2. Запустите ruby trigger.rb
  3. Разделите проект B на B ', напишите другой скрипт, чтобы убедиться, что все коммиты синхронизированы с проектом B'
  4. Перейдите на страницу настроек проекта, создайте новый веб-перехватчик с URL-адресом http://7e9ea9dc.ngrok.io/payload для проектов A и B '
  5. Добавить Project Monitor в Travis CI

Таким образом, разработка A и B не затрагивается, и новые сборки могут запускаться автоматически.

person Endle_Zhenbo    schedule 13.01.2016
comment
Красиво смотрится (в дополнение к моему ответу)! +1 - person VonC; 13.01.2016