I have configured some new plans to run by polling the Subversion repository. Neither plan is triggered after changes. In the Bamboo application server log, I see messages like the following:
Never checked path [<Subversion URL>] for plan <PLAN-KEY>, setting latest revision to 12345
Does anyone know what this message means and why the builds are not being triggered? We had the Subversion Source Repository option "Include / Exclude Files" configured previously with a regular expression to prevent non-code changes from triggering the build; we have since changed the option to "None", but it hasn't helped.
The error appears to point that the latest revision has a null entry and as such it default to the previous value probably. Can you confirm whether you are using polling repo strategy or the build on commits? Can you also run the command svn info to see the latest revision returned
I am also wondering if you can try to run manually and then try the trigger again
I am using the polling strategy. The working copy exists on a remote agent machine, there is no working copy on the master build server. The "never checked path" appears in the master build server's log.
Running the build works fine when triggered manually. It does not change the behaviour, though: version control changes still do not trigger builds.
I would also add that the build plan in question replaces one that was moved from the same project and plan keys. Could something be lingering from the previously existing plan that is confusing the master build server polling mechanism?
I've tried deleting the Source Repository for one of the plans and recreating it. Well, it worked -- kind of, but it has also made things worse in a way. Instead of never triggering, the build plan is now triggering repeatedly even though no changes have been made to the repository since the previous build. Subsequent builds report that the same change triggered them.
In the five years that we've been using Bamboo. I've never seen anything like this. :)
The build was apparently not triggering incessantly, as I first assumed. It was merely triggered as many times as there had been committed since it had last been manually triggered. That is, there were 8 commits between the time that it had last been manually triggered and the time that I recreated the Subversion Repository for the plan. So, the build triggered 8 times (but always cited the most recent change has having triggered the build).
Long story short: Recreating the Subversion Repository at the plan-level fixed the problem.
I'm John Allspaw, co-founder of Adaptive Capacity Labs, where we help teams use their incidents to learn and improve. We bring research-driven methods and approaches to drive effective inciden...
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