|
I have had experiences with cruise control, were a build would start before all the files were checked in, and therefore fail. There was a configuration option in that product to delay a certain number of seconds and check for further checkins. So, this has come up for me in my large build environment.
BTW, I in no way advocate emulating the above mentioned product In CVS this was definitely an issue. The whole point of Subversion's atomic commits was that you would never have an unstable tree as you could have in CVS. If we use the above example, what's to stop a user from doing an update between the two commits and getting a sandbox that has errors in it? As you point out sometimes the scan for changes can be slow, but if the user knows what had changed (as in the example) then every SVN tool I'm aware of will allow you to simple select those files for update. I really would discourage bringing the quiet period concept to SVN since one of it's main design goals was to eliminate the need.
If the above didn't convince you, here's another real-life scenario. Developers are spread across continents. The next build should contain changes from both of them. They agree (over the mailing list / phone) they are ready to go with their changes which are complimentary to each other. There's no technical way to commit those in one changeset, isn't it? So, they want to commit at the same time, and have the server pick their changes altogether, not randomly jumping in.
The transactional nature of changesets in SVN was designed with different goals in mind, and it does it well. We're discussing a higher-level feature. Consider the difference between an ACID transaction in itself and a BPM solution with compensating transactions. I don't understand why this is required. I want the opposite (BAM-1248), where every commit is guaranteed to generate a single build.
Andrew, it sounds like you want to make a breaking commit to the repository, but not have the build fail. If the team doesn't want to fail the build, they should ensure the repository is never in an inconsistent state. If the repository is ever in a broken state, it's the responsibility of the build system to report that. For the former real-life scenario (involving multiple components), you can version your components using a dependency management system like Maven or Ivy. Don't change the version of component A that component B depends on until the changes to component A have been committed, tested and released as a new version. This is how we manage our internal dependencies at Atlassian, for example. For the latter real-life scenario (involving geographically-separate interdependent commits), how can the developers be sure that their changes will even function together without consolidating their work first? The only sane way to commit this kind of work is to integrate it all on a single workstation and test it before committing. Anything else is more likely to fail the build simply due to incompatibilities, even if Bamboo did wait to pick up both commits. This could be useful even in Subversion. I am often encountering this problem: I make an atomic Subversion commit which contains interdependent changes between multiple Bamboo build plans. Bamboo then does not always build the plans in the right order.
Guys, what you are telling is all nice, but face the reality - if you reject this feature as in 'you should do it this (right) way', the one to lose would be Atlassian, by angering users with the lack of such trivial and expected feature.
That sounds much the same as 'distributed transactional systems must never fail because you have a fully-functional XA transaction manager'. Guess what, they fail, and to the extent that standard heuristic exceptions have been introduced to denote cases when it gives up and requires manual intervention/resolution. Don't fix the world, this attempt would fail. Guys,
We're not rejecting the feature by any means and I believe this and BAM-1248 can co-exist quite happily as options. Which one you go for really depends on your setup. If you have a project with a 100 commits a day and 40 minute builds (like Andrew has) On a general note, I guess this is why we have our issues public. This issue already has quite a few votes and many watchers, so it's fairly clear that your use case is far from uncommon. When we address the atomic commit issue, we're quite likely to address this issue as well. Cheers, Mark C PS As a side note, Matt's a Confluence developer, so he's just putting his 2 cents on this topic, rather than making a call on behalf of the Bamboo team. In JIRA land, he's still only got one vote An additional use case for me in support of this feature. We require meaningful comments (e.g. brief description of the change made to the file, JIRA issue key related, etc.) to be attached to each file checked in to our SVN repository. Therefore, if I'm checking in 6 files and each needs a different comment, often times the polling interval will pass before I'm done checking in each file. This will result in a broken build if all 6 changes are necessary for the tests to pass.
Folks,
This will be available for the next beta (beta7), which will come out next Tuesday. It's implemented as an optional advanced setting for SVN. Cheers, Mark C Great to hear! We'll give it a spin once published.
Hi guys,
This feature is now officially released in Bamboo 2.0! For more information about the release, check out our release notes You can download the latest release here Regards, |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Resolved
Major
An option to delay building after checkout detected for SVN
You're on the right track, but do not neglect the experience of other build server systems.
Regarding issues you've mentioned, none of them were really a problem for the past 2 years of actively using various build servers on my side. All concerns fade away for a build, which e.g. lasts 40 minutes. Well, Bamboo is a commercial offering, so I hardly believe people would pay the price tag for a build system managing 2-minute builds.
So, another use case from me
You're on the right track, but do not neglect the experience of other build server systems.