Is it possible to replace the entire Repository Url with a parameterized string in Hudson/Jenkins?

Question

In Hudson/Jenkins, is it possible to replace the entire string in the Subversion Module Repository URL with a String parameter? I don't want to just replace just the version or anything like that, I want to replace the entire url.

So, when I run the build, I'd get a prompt for the URL and I'd put something like "http://scm.work.corp/svn/com.work.package/tags/project-4.0.0.RELEASE" and it would check that out and build it.

Being able to substitute the "com.work.package" and "project-4.0.0.RELEASE" parts would be just as acceptable. I basically want it to be one job that can build any release.

Astound

Answer 1

I suppose I should have specified my use case.

I understand the purpose of Hudson. The only reason I want this is to have Hudson perform a single build for a release that the user specifies so that a plugin we use (sonar) can be triggered without having to add it in every pom and attach it to every phase. We do our releases manually so we don't want Hudson to handle that. However, we do want sonar reports on our releases, thus this use case.

However, this actually turned out to be easier than I expected. I simple did a parameterized build and put ${PARAMETER} in the svn repository url. Now, Jenkins given me an error saying that's an invalid URL, but actually doing the build works as I expected it. I'm glad I tried it out despite that error warning.

Astound

I'm using hudson, but i think this should work with Jenkins also. I'm using repository URL in following format svn.apache.org/repos/asf/hadoop/common/trunk@$ApacheRevNumber where ApacheRevNumber is a parameter I define using "this build is parameterized" option – Adrianeadrianna

Answer 2

Yes, you can. But you can't have Jenkins/Hudson monitor the SVN for changes. Even with parameters in place, that didn't work for me properly. But if you monitor the SVN from a job that does not have the Repository URL parameterized, have that job trigger a downstream job passing the entire Repository URL as a parameter, then have the downstream job use the Repository URL parameter, then it seems to work.

This is what we do for our build stuff. We have one job that can build the product from SVN, based on the Repository URL that you start the job with. Then we have a number of trigger jobs that monitor certain branches; when a change is noted, the startup the build job and pass their URL to it.

Exploratory

Just as an addition, you need to use the $xxx format and not %xx% format to refer to your build parameter (where xxx is your SVN path). – Antitrust

This worked for me, allowing me to choose what branch to pull from on a downsteam build. I'm using Jenkins 1.575 with SubversionPlugin 2.4.2. I have an upstream job that has the SCM monitor, the downstream is triggered by upstream success. Note that when setting the variable in the SCM settings, it will complain that path.to.svn/yourepo/$repo_path does not exist, but it will still checkout and build properly. – Christoperchristoph

Answer 3

If Hudson/Jenkins doesn't know the URL in advance, how is it suppose to do continuous build integration?

And, how does Hudson/Jenkins do an update if you keep changing the URL? You'll have to get Hudson/Jenkins to either do a fresh checkout each time, or get it to use the svn switch command.

The whole purpose of a tool like Hudson/Jenkins is to do continuous builds which you want to stop it from doing. Since you're not doing continuous builds, why bother with a tool like Hudson/Jenkins? Why not write your own Ant script that will checkout what you want and then do the build?

Each branch and each module should have its own Hudson/Jenkins job, and with the template plugin, you easily copy one job to be the template for another job. So, it's not all that difficult to setup all the builds you need.

Band

I understand the purpose of Hudson. The only reason I want this is to have Hudson perform a single build for a release that the user specifies so that a plugin we use (sonar) can be triggered without having to add it in every pom and attach it to a certain phase. We do our releases manually so we don't want Hudson to handle that. However, we do want sonar reports on our releases, thus this use case. – Astound

Sonar works fine with periodical builds, it's just the releases we needed to handle specially. – Astound

There are many reasons why you might need to do this, which is why the "build triggers" section in the job config lets you uncheck "poll scm". – Antitrust

Answer 4

Yes you can, I had the same issue but changed it to $VARIABLE and seemed to work the only issue was that you have to include a "." in the Local module directory. It took me a long time to find this out.

Wistful

Answer 5

You can do it, but you can't have Jenkins manage svn for you. Create a parametrized build, with your strings, then in the execute step, do a svn co ${parameter_you_selected} plus whatever else your build steps are (call ant scripts, makefiles, rakefiles, etc)

Moderato

Answer 6

Yes you can. Check Building a specific SVN revision with Hudson. In this case it just parameterizes the suffix of the URL. In your case you need 2 params for "com.work.package" and "project-4.0.0.RELEASE".

Hope it helps!

Tanager