Возможно https://ci-bayes.dev.java.net / или http://www.cs.cmu.edu/~javabayes/Home/node2.html ?
я никогда не играл с ним также.
В Hudson вы можете связать несколько заданий вместе. Вы можете попробовать создать отдельные задания Hudson для test_framework и еще одну для project_a. Хадсон создает отдельный каталог в $ WORKSPACE для каждого задания, так что теперь у вас должно быть два разных каталога в $ WORKSPACE.
Цепочка настроек
В конфигурации задания project_a прокрутите вниз до Действия после сборки и отметьте Сборка других проектов ... Введите test_framework в качестве проекта для сборки.
В конфигурации задания test_framework убедитесь, что опрос SCM не отмечен , а для параметра «Сборка после других проектов» установлено значение project_a.
Как это работает
Что вы сейчас настроили, так это то, что project_a будет опрашивать SCM в поисках изменений, а при обнаружении изменений извлекает их из git.
Проблема с решением «Сборка других проектов» заключается в том, что при внесении изменений в test_framework он не запускает сборку project_a. Вместо этого я рекомендую отказаться от подключаемого модуля git и настроить этап сборки «Execute shell» следующим образом:
rm -rf ${WORKSPACE}/*
git clone ssh://server:/repo/test_framework.git ${WORKSPACE}/test_framework
cd ${WORKSPACE}/test_framework
git fetch -t ssh://user@server:/repo/test_framework.git +refs/heads/*:refs/remotes/origin/*
git ls-tree HEAD
git clone ssh://server:/repo/project_a.git ${WORKSPACE}/project_a
cd ${WORKSPACE}/project_a
git fetch -t ssh://user@server:/repo/project_a.git +refs/heads/*:refs/remotes/origin/*
git ls-tree HEAD
Затем создайте файлы ловушек «server: /repo/test_framework.git/hooks/post-receive» и «server: /repo/project_a.git/hooks/post-receive "со следующим содержанием:
#!/bin/sh
curl http://hudson/job/job_name/build
Теперь, когда изменения помещаются в любой из репозиториев, ловушка будет использовать API Hudson для запуска сборки.