SVN Plugin : Using Global Properties in SVN URL

[Jean-Luc Pinardon]

Dear all,

I wanted to use parameter to define the SVN URL in the Source Code Management section.
I made 2 tests :

   1. with var defined as Global Props in the server config
   2. with var defined as properties within a file passed to the job thanks to the setenv file plugin (Set environment variables through a file)


Surprisingly, none of both methods works.
It appears that Global Props are not taken into account (no idea why) and properties are read after files are checked out, which seems to me not really consistent with the idea of setting environment. AMHA, to set the job environment should be the first thing to do.

So, it appears that the only way to parameterized the SVN URL is either

   1. to trigger the job with a preceeding one only in charge of setting up the environment,
   2. or to parameterized the build.


Am I wrong or is it the "normal" behaviour ?


Best Regards
J-L

[mattinger1]

I've found this to be the case with many plugins.  It's also unclear in many cases, which fields support variable replacement and which don't.

Also, even when they do, it's unclear when you should use ${variable} as opposed to %variable%   (assuming you're on windows this is a big

issue.

Compare this to quickbuild, which I'm a longtime user of, where virtually every configurable item is scriptable.

Hudson has a great community behind it, and being open source, means I can extend it to do what I want.  That being said,

there's lots of ideas from other products (like quickbuild) that i'd love to see make it into Hudson (Jenkins), such as hierarchal

build configurations, deterministic build step ordering (defining an absolute flow which includes fork and join points for parallel

step execution), an artifact publishing area, and most of all, full scriptabililty of configuration items.

To the developers, keep up all the good work.

[mattinger1]

I've found this to be an issue with several plugins. It's very spotty
and unclear which configuration items support variable replacement,
and which don't.

Being a longtime user of Quickbuild, I love alot of the ideas that are
in that product, and virtually every configuration item is
scriptable. That being said,
quickbuild is a more heavyweight installation, requiring a real dbms
(using the out of the box hsqldb is not a good idea), and the
community version is
limited in the # of configurations.

Also, Hudson/Jenkins has a much larger community, and a ton of
plugins. Though many of those plugins are to support things built
natively into quickbuild.
Plus, being open source, I can write a plugin to do whatever I want,
which is not necessarily the case for quickbuild.

I'd love to seem some of those ideas make their way into Jenkins
(hierarchal build configurations), scriptability, publishing storage,
etc...

[do...@fortysix.ch]

I absolutly agree with you, in fact I raised a question about this on
the dev list:
http://hudson.361315.n4.nabble.com/Enhance-Parameterization-td3092100.html
but unfortunately I did not get any respond to it...
/Domi

Zitat von mattinger1 <matt...@gmail.com>:

[Sami Tikka]

Jean-Luc Pinardon kirjoitti 26.1.2011 kello 10.08:

> It appears that Global Props are not taken into account (no idea why) and properties are read after files are checked out, which seems to me not really consistent with the idea of setting environment. AMHA, to set the job environment should be the first thing to do.
>
> So, it appears that the only way to parameterized the SVN URL is either
>
> 1. to trigger the job with a preceeding one only in charge of setting up the environment,
> 2. or to parameterized the build.
>
>
> Am I wrong or is it the "normal" behaviour ?

I guess it depends on what you define as "normal".

I myself understand that the Subversion URL is used as-is by Hudson because Hudson SVN plugin has a pure Java SVN implementation. There is no external svn client invoked via shell that would expand $VARIABLES from environment before executing the client.

The environment variables are available for build steps, because the build steps are executed by a shell, which expands any $VARIABLES. Also, Hudson adds a couple new variables to the environment of the build step.

OTOH there are so many people who seem to think Hudson should expand $VARIABLE or %VARIABLE% in _any_ input by the user that maybe that is "normal", after all.

The Hudson developers have probably had a lot on their minds lately with the Hudson/Jenkins rename and all. When the dust settles a bit, you could try to engage them (here or in the developers list) and convince them what is "normal".

If you can come up with a patch that implements your vision of "normal", I'm sure that will help them understand you better and get it fixed faster. Hudson/Jenkins is open source software and developers usually scratch their own itches. If this is your itch, go ahead and scratch it :)

-- Sami