We have SVN code repository and bamboo is configured to poll every 180 seconds to check whether any code has been checked in. Every check in triggers a new build. However 60% of the builds triggered are failing at "Poll and Build" Stage without generating any error log. Its hard to understand why the builds are failing intermittently.
I would really appreciate if I can get some help from the team to understand whether this issue can be debugged.
NEOGOV developers team
Without the Bamboo server log or the bamboo agent log, if this is happening after the build has been started, it's a bit difficult to help you.
But yes, it can absolutely be debugged.
Thanks. These links will help.
My builds are now succeding. I created a new agent and added a new MSBuild builder specifically for one solution (which was failing). This helped me to segregate the build definition from rest of the projects and polling started functioning correcty.
Is there any standard in terms of how many projects/solutions should be linked to one Builder? Also as a best practice, should we have a separate agent for each project just to keep the stuff clean and reduce the load on the agent and builder?
NEOGOV developers team
When you say a new builder, do you mean a new msbuild build task for each solution or a different plan?
At my last job I had one build that contained something like 80 tasks in a single plan stage.
Something under half of those tasks were msbuild tasks and they built either solutions, or projects depending on, well, dependencies. We had several .proj files we built separately even when they were rebuilt in solutions later in the build because they produced dependencies consumed by the solutions as I recall.
I'm not an expert on msbuild by far, but it seems to me to be largely a preference item. Or one driven by dependency management requirements.
We built the whole shebang and then deployed files rather than msi's or exe's. We did it that way initially because the sr. developer dude thought we should always deploy the entire application. Later I think he realized that was a bad idea for that app (due to size and complexity and fragility), but he quit and went to work somewhere else before we were forced to do things differently.
As a project manager, I have discovered that different developers want to bring their previous branching method with them when they join the team. Some developers are used to performing individual wo...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs