Я новичок в jenkins и, возможно, не понимаю тему CI еще полностью. Учитывая мои исследования, я обнаружил, что если я сделаю CI, у меня всегда будет стабильная сборка. Теперь это как-то меня смущает, так как я ничего не нашел в дженкинсах. Мое понимание этого заключается в том, что у меня есть репо. Дженкинс основывается на этом репо, после того, как каждый мой проект будет проверен дженкинсами и будет построен. Но что, если фиксация действительно нарушает сборку? Это означало бы, что мой репо тоже сломается. Теперь я ищу способ решить эту проблему. Моя основная идея для этого atm заключается в том, что у меня есть 2 repos. (я использую subversion)
1. Repo: Этот получает все обязательства от разработчиков. Дженкинс строит проект на основе этого.
2. Repo: Всякий раз, когда проект становится успешным, совершите госование в этом репо. Я не уверен, как это сделать, так как я не нашел ничего связанного с этим в моих этапах после сборки в моей конфигурации проекта в jenkins.
У вас есть идея о том, как я мог реализовать эту конфигурацию?jenkins commit после успешной сборки
3
A
ответ
2
Jenkins не имеет встроенной поддержки для «предварительно протестированного фиксации», что и похоже на то, что вы ищете. См. https://wiki.jenkins-ci.org/display/JENKINS/Designing+pre-tested+commit и https://issues.jenkins-ci.org/browse/JENKINS-1682. Если вы использовали git как свою систему контроля версий, похоже, что там были некоторые усилия (см. http://jenkins-ci.org/content/pre-tested-commits-git).
Если вы ищете систему, которая делает это из коробки, вы можете проверить TeamCity и ее "pre-tested commit" feature. Однако это не бесплатный продукт.
У вас это выглядит хорошо. я думал, что у каждого хорошего CI-сервера есть какая-то такая функциональность, так как это выглядит очень важным для меня? Я также попробовал плагин revert, но он только восстанавливает нестабильные сборки, а не неудачные. нет ли шанса иметь аналогичную функциональность у дженкинсов? я имею в виду, где смысл в CI, когда вы не можете работать, потому что вам нужно подождать, пока разработчик не исправит сборку, которую он испортил? или понять это неправильно? – jig
Самое главное в CI - быстро ловить проблемы, чтобы избежать проблем интеграции. Следующим шагом является предотвращение того, чтобы проблемы попадали в исходный контроль, о чем вы говорите. Существует еще большая «победа», чтобы использовать CI даже без дополнительного шага предварительно протестированного фиксации. –
И на самом деле, я думаю, что вернувшийся плагин SVN также вернет изменения для неудачной сборки, так как я думаю, что неудачные сборки также считаются нестабильными. Вы можете проверить это, чтобы быть уверенным. Тем не менее, было бы лучше не допустить, чтобы код попадал в SVN в первую очередь, но я не думаю, что в настоящее время в Jenkins есть поддержка для этого в настоящее время. –