Nick V
Nick V

Reputation: 1843

Do svn import or add+commit in Jenkins?

I would like to make Jenkins add its build artifacts - in my case test results - to a svn repo. I need to add+commit or import the new created results files - unversioned files - into a svn repo. This ResultsFolder does also contains older files from older test runs which are versioned. The repo was checked out by Jenkins first.

Is this the way to do it?

  1. Add build step in Jenkins, Execute Windows Batch cmd (Jenkins runs on a Windows machine)
  2. Svn add cmd: svn add .\ResultsFolder\* to add all files of folder "ResultsFolder" recursively. The folder contains also versioned files and folders, is this a problem?!
  3. Svn commit cmd: svn ci . to commit previous add to the repo.

The reason why I do this is because the test results need to be:

  1. Backuped
  2. Checked out on another machine for further analysis

Upvotes: 0

Views: 3657

Answers (3)

ATOzTOA
ATOzTOA

Reputation: 35950

This is what I did for my POM file:

rem
rem Update SVN with pom.xml file with bumped version
rem
svn co "SVN PATH" %WORKSPACE%\temp --depth files
cd %WORKSPACE%\temp
cp ../pom.xml .
svn ci pom.xml -m "Jenkins : Version Bump"
rd /s /q %WORKSPACE%\temp

Upvotes: 0

David W.
David W.

Reputation: 107040

Here's a problem: Whenever you have Jenkins check in a new Subversion revision, it'll fire off another Jenkins build. You probably don't want that. Plus, you shouldn't check into Subversion something that is generated by the build. It'll quickly cause your repository to grow beyond your current disk size, and you'll end up with a ton of artifacts in your repository no one is interested in. Instead:

Use the archive abilities of Jenkins to save your build artifacts.

This makes them much more visible and easier to find. Plus, you can automatically have Jenkins get rid of them when you're no longer interested in them. Remember you can lock a Jenkins build in order to prevent artifacts you do want to keep (such as an actual release binary) much easier to find.

Plus, your other machine can use wget or curl to pull them off the Jenkins repository.

Use the Copy Artifact Plugin for your other job.

If the another Jenkins job that requires these artifacts is another Jenkins job, you can use this plugin to copy the artifacts from this job into the other job, and automatically execute the second job. I do this when I have tests to run against a build that might take more than a few minutes to run.

Go All Out and Use Maven

Even if you're not using Maven as a build process, it's a great way to store and manage artifacts. Jenkins can store artifacts in Maven as part of the build process, and you can use wget, curl, or even Maven itself to automatically fetch the artifacts from the repository.

This is a bit more complex, but it's a defined standard method that's independent of Jenkins. This is nice if you decide to move from Jenkins to say TeamCity. You're not stuck depending upon a proprietary process in Jenkins.

Upvotes: 2

Manfred Moser
Manfred Moser

Reputation: 29912

Why dont you look at using Sonar instead of reinventing it?

Upvotes: 0

Related Questions