I found this: Plugin to commit hudson build artifact but after ~5-6 hours of trying every combination of settings imaginable I have not been able to successfully commit to our https' svn.
I am considering doing this through a batch file -- but have no idea if it is possible to obscure the password... if it isn't then this isn't really an option, either.
Is anyone doing this successfully? Could use some advice.. thanks.
The main problem is that Tortoise doesn't come with a "real" SVN command line client. The command line can barely commit - it instead opens a window and prompts for more info.
Have you looked at the Maven release plugin? You use it with a SVN command line (not Tortoise). You can encrypt Maven passwords. While I've used these successfully for Nexus, I haven't tried using them to access SVN yet though.
I ended up just using a batch script to check out my target folder, copy files to that folder, add them to SVN, and then commit the files. The only snag was supplying credentials. My solution was to log into the machine that Hudson was executing on and manually commit once. This allowed me to 'save my login details' encrypted on the build server. Ideally you should use a limited-access account to do this step.
I would not commit Subversion built files back into the Subversion repository. That's just asking for trouble. Once you commit something to Subversion, it stays there forever. You can never remove the obsolete information.
Text file changes aren't so bad because they diff quite nicely, and Subversion stores each revision in diff format. However, binary files don't diff all that well. If your binary output is 500 Mb in size, each commit will add 500 Mb into your Subversion repository. Do this with Hudson, and do this after each and every build, and you're talking about hundreds of gigabytes of data in less than a year -- and most of that will be obsolete version of your code that you simply don't need.
Use Hudson itself to store your builds. One of the steps in your build process is to Archive the Artifacts. I simply use my build file to copy all the artifacts I want to store into a target/archive directory, and have Hudson store that.
We define the Hudson job to Delete Old Builds, but leave the Days to Keep and Maximum to Keep blank. Instead, we click on the Advance button and specify how long to keep the Artifacts. This way, we never delete a build, but we keep the Hudson server with enough room on it.
In a particular build, you can click on Keep this build forever, and it will save the artifacts instead of deleting them. This allows you to keep the artifacts that have been released, but still will remove the daily build stuff you're no longer interested in.
You can even use wget or curl to get the artifacts and deploy them. We do this with our deploy scripts.
If you want to get fancier (and who wouldn't), put your build artifacts in a Maven repository. You can do this even if you don't use Maven for your build process. Again, this stores your artifacts, but allows you to delete and trim down the ones you don't want to keep.
If you really, really want to store your build artifacts in Subversion, you can do what you did with the batch file, and use svn co and svn commit -m"Some sort of message %BUILD_NUMBER%" commands to do it. However, once something is in your Subversion repository, it's very, very difficult to remove it. Be prepared to burn through gobs of diskspace.
Try adding following piece of script in 'Execute shell' under configure.
echo "Committing build.number file to SVN.." cd $APPROPRIATE_PATH svn commit -m "some svn commit comment" MyApp/etc/build/build.number echo "Build file committed "
