Subversion checkin from build plan?

[Jeff Bragg]

I've searched around the FAQs, KB, etc, but haven't found anything that seems to be related to this. My company uses Maven projects heavily, and we've been using the Maven release plugin to cut our releases. To make this a less tedious and time-consuming process, we're trying to create specialized, manually-triggered-only build plans that can orchestrate these releases. In addition, many of our projects are Grails projects, which introduce another bit of complexity to the release process, as they include a file called application.properties that must be updated and checked in before the release plugin runs (to set app.version to the release version, rather than the snapshot version), and then updated and checked in again afterward (to set app.version to the new snapshot version). The release plugin itself likewise needs write access to Subversion (which in our case is also Atlassian-hosted). I've worked out the logic to automate these things, but I'm running into a problem when the stage that takes care of updating this file attempts to check it in. Specifically, I get an error that includes the following (with specifics about locations removed for posting here):

": authorization failed: Could not authenticate to server: rejected Basic challenge"

First I should say, I assume there's a 'bamboo' user automatically in our hosted Subversion instance which allows the builds to checkout. I'll further assume that it has read-only access, as this error looks to me not so much like the server didn't get the credentials, but that the user couldn't perform that operation.

So my first actual question would be, is this accurate?

If it is accurate, is there anyway to allow the bamboo user write access so it can perform these actions? If not, is the right way to work around it to create an account dedicated to the release process? I'm not certain my company would go for the latter, as it would have to be a developer-level account.

On a related note, this process has also brought to my attention the buildnumber.txt file. This is relevant because the Maven release plugin takes umbrage with its very existence in the checkout directory, claiming that there are local modifications, and it thus cannot prepare a release. While this is clearly a limitation of that plugin, since it's not distinguishing between a file that has been moved/added/modified/deleted and one that Subversion just doesn't know about (the latter of which it should be content to ignore, IMO), it still will ultimately stand in the way of the release plugin's activity. I've tried deleting this file during the process, but it still seems to be there at the time the release plugin attempts to run. Looking at it on the actual machine, it doesn't appear to be special (such as having the sticky bit set), but my task seems either silently to fail to remove it, or the file to be replaced anyway. I know that Bamboo uses this file, but is it safe to remove it temporarily for these purposes?

[Przemek Bruski · Accepted solution]

Yes, you need to use the username and password options to access Subversion- the agent does not leak credentials to othe processes.

You can safely delete the build number file, it's not used by Bamboo - it's meant to be used by user scripts, if you don't need it, just delete it.

[Jeff Bragg]

Actually, I may be wrong about the nature of that Subversion error. For troubleshooting purposes, I added a task that just tries an svn update, which shouldn't run into permissions errors, as it's not trying to change anything, and the resulting message was essentially the same. So perhaps I can work around the main issue by explicitly providing --username and --password options.