Обычно вы будете использовать Дженкинсу немного по-другому. Вы можете делать именно то, что хотите, но Jenkins и python могут устранить некоторые из вас.
Во-первых, у Дженкинса есть возможность проверить материал из различных систем управления версиями, включая Subversion. Это обычный способ использования Дженкинса. Когда вы настраиваете задание, вы указываете адрес своего репозитория управления версиями, после чего вы настраиваете шаги для выполнения после того, как файлы были извлечены.
Во-вторых, вы должны использовать тестовую платформу python http://docs.python.org/library/unittest.html, чтобы написать свои тесты. Затем вы можете использовать, например. утилита nosetests для запуска тестов. Nosetests могут даже создавать тестовые отчеты в формате xml, и Дженкинс может читать отчеты и показывать вам, какие тесты не удались, и почему они потерпели неудачу (если отчет содержит эту информацию.)
Но ответ на ваш вопрос: если вы выходите из этапа сборки с ненулевым кодом выхода, Дженкинс будет интерпретировать это как означающее, что сборка завершилась неудачно, и она будет отмечать эту сборку красным шаром.
Дженкинс может отмечать сборки как стабильные (зеленые), неустойчивые (желтые) и не сработавшие (красные). Если шаг сборки завершается с ненулевым кодом выхода, сборка завершилась неудачей. Если шаг сборки завершается с нулем, Jenkins может быть настроен на поиск файлов отчетов об испытаниях. Если тестовые отчеты не прошли тесты, сборка будет неустойчивой. Если все тесты пройдены, сборка будет стабильной.
Обычно люди используют неисправный (красный), чтобы указать на фатальную проблему в тесте (например, неспособность установить программное обеспечение, которое должно быть протестировано), а затем использовать отчеты об испытаниях для указания нестабильной или стабильной сборки.