11

I have a saved project in Subversion repository and compiles it with Jenkins. When I run the build, Jenkins pulls project into workspace directory. I need commit one changed file from Jenkins workspace into Subversion. How can I do it??

Thanks for answers...

jjaros
  • 498
  • 2
  • 4
  • 18

3 Answers3

5

Can you give a few more details? Exactly what is this file, and why does it need to be committed as part of your Jenkins build? What are you building (Java? C++? .NET?) and how are you building it?

Normally, you shouldn't put anything under version control except source files. That is, if you can build it, you shouldn't put it into version control. A lot of people like to commit their built code into their version control system, but this is usually a big mistake. binary files are much bigger and rarely diff. This results in a source repository that's 90% compiled code -- almost all of it obsolete. This is especially problematic with Subversion which doesn't have a way to (easily) remove obsolete code.

Jenkins has a feature that allows you to archive your built files for easy access. We use this all the time. We build our code, and the program is available in Jenkins for downloads. Even better, Jenkins will delete older builds (you can save the last X builds or save only builds younger than X days). And if you have a release candidate build, you can lock that build to prevent it from being deleted.

Still, if you insist on doing this, there are several things you can do and things you have to watch out for:

  1. When you have Jenkins setup to automatically build each change, and you commit a change in your version control system, Jenkins will see that, and start a new build. Then, Jenkins saves the change, sees the change, and does another build. Make sure you exclude the files or directories from Jenkins' consideration when it should do a build. You can specify this when you specify the URL of the checkout.

  2. Unlike most version control systems, Subversion was made to be client independent. There's an actual API for clients. The standard Subversion command line client isn't needed in Jenkins, so make sure it's installed. Make sure you install a client compatible with the Jenkins built in SVNKit client. This is especially true since Subversion 1.6, 1.7, and 1.8 all take a different client format.

  3. You can add multiple build steps to your build in Jenkins. Just add a new shell script or batch script step, and add in a svn commit -m "comment of some sort" step. It's pretty simple to do once you've taken care of the first two points. However, please think carefully why you're doing this.

As I said before, 99.9999% of the time, you shouldn't be using Jenkins to commit changes it built. I'm sure that 0.0001% reason exists somewhere, but I've never seen it. If you want to make built files universally accessible to your other projects, use Jenkin's ability to archive built files.

If a product Jenkins is building is needed for another build, you can use the Copy Artifact Plugin to copy a build artifact to another job, and then fire off that job. Even better, use a release repository system. In Java, you can use a Maven release repository like Nexus or Artifactory. To use and deploy artifacts to that repository, you can use Ivy or Maven or Gradle. If you are building .NET, look at Nuget.

David W.
  • 98,713
  • 36
  • 205
  • 318
  • 2
    one reason I've seen to commit in a build is to increment the release version as part of an automated release. Certainly, there are other ways to do this and other tools, but it's more common than 1 in 10^6 :) – Dave Bacher Jan 23 '15 at 17:11
  • There's no reason to check in anything in that case. You have a file that contains a template string that gets replaced with some version number. In Subversion, you can use the Subversion revision number. Even better, we use the Jenkins job name and the build number, so we can go back to the Jenkins build which shows us things like testing data, and helps us trace the history. Otherwise, all you're doing is creating thousands of Subversion revisions that contain absolutely no useful history information. You do a `svn log`, and 50% of the changes listed are due to the build. – David W. Jan 23 '15 at 20:21
  • 1
    I'm certainly not suggesting committing with each and every CI build. Clearly, we're using different terminology, release build != build. In the case I describe, there is a public-facing "marketing" version number that increments with each *release* build. – Dave Bacher Jan 23 '15 at 21:19
  • I'm sure that question is valid for some use cases and all this teaching around is not necessary. Or might be for somebody, I'd put it as a side-note. – LiborStefek Feb 19 '20 at 07:47
2

Please have a look to this answer: Jenkins svn commit post-build

It should be possible to commit with a new build step (or a post build step).

But be careful with the SVN layout of the Jenkins workspace. The subversion plugin is using the SVNKit to deal with the SVN commands. Your workspace maybe use the SVN layout 1.6.

If the SVN client is more recent on your machine, your SVN commit will fail with the following error: org.apache.subversion.javahl.ClientException: The working copy needs to be upgraded svn: Working copy 'C:.... is too old (format 10, created by Subversion 1.6)

Community
  • 1
  • 1
Bruno Lavit
  • 9,486
  • 2
  • 27
  • 37
1

You could carefully use: 

svn commit -username someuser -password %injected_password%

to inject password in Build Environment, this command injects passwords to the build as environment variables

Watch out: that password might be visible in the job trigger batch.

Louise Davies
  • 10,919
  • 4
  • 33
  • 35
Ato
  • 11
  • 1