Yes, this is my long-term goal – that way we can reduce the amount of network traffic to and from the server.

However, like anything, it requires time – which always seams to be a precious commodity So, feel free to provide any input, it’s always good to get advise, feedback, code, etc.

Craig

Thanks!

The WriteRequest(IntegrationRequest request) method in XmlIntegrationResultWriter only has the Integration properties (prefixed with CC) as BuildValues, not the dynamic parameters, so they don’t appear in the log.

When you run a second and any subsequent build, they do appear. The dynamic parameters are just not included in the XML log on the first build.

Thanks for the bug report – you are right, it should not do this

Craig

Craig

Craig

I got a bunch of selectParameters working nicely with a sub-element of allowedValues. Works fine from CCTray and web interface.

However, when I create my own client, and call ListBuildParameters for the project, I get the full ParameterBase collection, but the allowedValues string array is always null.

Any ideas? It has to be something simple I’m missing, I reckon.

Thanks,
Wim

My only complaint is that sometimes when I force a build from the Visualisation pane, all the other projects go gray and only revert to the right colour after the build has finished.

But we must make sure that there are not too many of these tasks in CCNet core. All these tasks are also maintenance
As long as it is calling exe A with arguments X Y Z that should not be a big problem.

I ended up doing some profiling with dotTrace. The result files ended up being enormous. And the memory usage was horrendous. The worst bit was actually on the exception path. While one of the exceptions (about being out of memory) was bubbling, the code tried to append “Error: ” to the standard output and, exactly as you described, it resulted in an enormous new string being allocated. Anyway, I guess streams really are the way to solve this.

Bring on 2.0!

%systemroot%\system32\inetsrv\APPCMD.EXE migrate config “Default Web Site”

Glad I’ve been able to help

To answer your original question – yes it is a convoluted way of doing things. Unfortunately it was the only way to do it using CruiseControl.NET – because under the hood we load the definitions into some POCO instances using NetReflector. Later on I modified NetReflector to allow the substitution method, but under the hood it just converts the XML into the “convoluted” definition.

One day we will have to look into this a bit better, but for the moment it works

Craig

Great stuff!

http://confluence.public.thoughtworks.org/display/CCNET/Dynamic+Parameters

So that presumably means you can use dynamic parameters without having to define a list in your appropriate build section of your project definition.

So I could simply use the builArgs element for the msbuild task as such:

/p:Configuration=$[BuildMode|Debug] /p:Environment=[Environment|Staging]

I hope I understood that correctly.

Also, is there a way that these dynamic params can be specified when forcing a build from the web app or the CCtray? Or is it only available through the client API at the moment?

Apologies for screaming too soon!

Thanks,
Wim

I’m toying around with the CTP version (1.5).

Isn’t this and overly convoluted way of doing this? We’re using MSBuild and have defined our own properties like ‘Environment’. Based on that, the appropriate MSBuild tasks will deal with this accordingly and generate output for the specific environments.

Ultimately, all I want to be able to do is pass an additional bunch of build args (/p:Environment:Staging and so on..) to a Build Project definition.

It looks like the current way of doing it only lets you substitute the XML element’s inner Text. And it seems a violation of DRY too, as you’d need to define the list of values in the ccnet.config file, but clearly we’ve already got it defined it our MSBuild files. Why the need for a list of defined values?

Am I missing a simple trick to be able to pass custom (but dynamic!)properties to the buildArgs of a defined project?

Thanks,
Wim

I did not have the time yet to look into the code of the branch
too many other things on my head.

Craig