3

I am new to jenkins and maybe do not understand the CI-topic yet completly. Considering my research i found that if i do CI, i will always have stable build. Now this somehow confuses me, since i did not found anything about it in jenkins. My understanding of this is, that i have a repo. Jenkins is based on this repo, after every commit my project gets checked out by jenkins and will be build. But what if a commit actually breaks the build? This would mean my repo is broken aswell. Now i am searching for a way to solve this Problem. My basic idea for this atm is, that i have 2 repos. (i am using subversion)

1. Repo: This one gets all the commits from the developers. Jenkins builds the project based on this one.

2. Repo: Whenever the project gets build successful the commit gos into this Repo. I am not sure how to do this part, since i dont find anything related to this in my post-build steps in my project configuration in jenkins.

Have you an idea on how i could realize this configuration?

jig
  • 73
  • 2
  • 8

1 Answers1

2

Jenkins does not have any built-in support for a "pre-tested commit", which is what it seems like you are looking for. See https://wiki.jenkins-ci.org/display/JENKINS/Designing+pre-tested+commit and https://issues.jenkins-ci.org/browse/JENKINS-1682. If you were using git as your version control system, it looks like there has been some effort there (see http://jenkins-ci.org/content/pre-tested-commits-git).

If you are looking for a system that does this out of the box, you might want to check out TeamCity and its "pre-tested commit" feature. This is not a free product, however.

Jeff Olson
  • 6,323
  • 2
  • 22
  • 26
  • ye this looks good. i thought that every good CI-server has some sort of such functionality since this looks pretty important for me? i have also tried the revert plugin, but it only reverts unstable builds not failed ones. is there no chance in having a similiar functionality in jenkins? i mean where is the sence in CI, when you cant work because you have to wait until a developer fixes the build he messed up? or do understand this wrong? – jig May 15 '13 at 18:55
  • the most important thing about CI is to catch problems quickly to avoid integration problems. The next step is to prevent the problems from making their way into source control, which is what you are talking about. There's still a big "win" to use CI even without the additional step of a pre-tested commit. – Jeff Olson May 15 '13 at 21:21
  • And actually, I would think that the SVN revert plugin would also revert changes for a failed build, too, since I think failed builds are also considered unstable. You could test it out to be sure. That said, it would be better to prevent the code from getting into SVN in the first place, but I don't think there is currently any support in Jenkins for this at this time. – Jeff Olson May 15 '13 at 21:25
  • the revert plugin is reverting only unstable builds, which is the desired way to function by the developers, at least this is the result of my research. i have also tried it out and it says: "not reverting because build is not unstable" even if the build actually fails. – jig May 15 '13 at 21:29
  • i have just read this [article](http://www.jamesshore.com/Blog/Continuous-Integration-is-an-Attitude.html) which explains the manual approach to CI. And i wonder about the second step "tell people not to upgrade after a commit which was not build+tested yet". This is a huge advantage compared to the automated approach with jenkins (for example), isnt it? since there no such feature, and everybody can update their code at everytime, no matter what? – jig May 18 '13 at 14:03
  • That article is pretty old. I don't think there are too many people suggesting a manual approach to CI today. Even at that time (2005) I don't think it was that good of an approach compared to a good automated CI system. – Jeff Olson May 19 '13 at 02:35