I would perhaps suggest creating the artifacts folder as (artefact
folder)\(BuildDate)T(BuildTime)[\(task name)] only because I have
noticed that some Labellers can re-use the same build number after a
failed build. This would result in artifact data being trashed which
could be relevant to the failed build.
[FLORIN] + [Craig] : I've set up IIS to have a virtual folder pointing
to my artifacts folder. My script generates an XML which is dropped
into this folder and then a link is created in the XSL (Simplified
version - some other magic has to occur too). My end user specifically
needs to be able to download the XML file.
This solution is fine all file types excpet .XML files which result in
an error screen:
"Server Error in '/ccnet/artifacts' Application."
I can get more details if I access this page on the local machine:
"An error occurred during the processing of a configuration file
required to service this request. Please review the specific error
details below and modify your configuration file appropriately. "
It seems that there is a problem with Cruise Control, there is a
section in the web.config:
<httpHandlers>
<!-- Yes, we are overriding .aspx - don't delete this!
We are
using .aspx since we know it is already bound to ASP.NET. In future we
might use a
different extension so that people can add
their own ASP.NET pages
if they want to, but we should make sure in that case to change how
URLs are created -->
<add verb="*" path="*.aspx"
type="ThoughtWorks.CruiseControl.WebDashboard.MVC.ASPNET.HttpHandler,ThoughtWorks.CruiseControl.WebDashboard"/
>
<add verb="*" path="*.xml"
type="ThoughtWorks.CruiseControl.WebDashboard.MVC.ASPNET.HttpHandler,ThoughtWorks.CruiseControl.WebDashboard"/
>
</httpHandlers>
This seems to be stopping me from creating links to XML files :( any
ideas anyone?
This may prove to be an issue for the new system too.
Cheers,
Shaun
On 12 June, 22:22, "Craig & Sammi Sutherland"
<[email protected]> wrote:
> In the 1.4.4 release we are starting to merge non-XML files into a build
> folder :-) We are using this functionality for the NDepend task, and in
> 1.5.0 this is being expanded to even more tasks (e.g. NCover, expanded file
> merge options, etc.)
>
> The build folder is (artefact folder)\(label)[\(task name)]. If the artefact
> folder is not defined in the project definition, then this defaults to
> (project name)\Artifacts, and I think it is stored under the current
> directory. The label comes from whichever labeller is configured for the
> project - by default this will increment an integer every build.
>
> To access this files from the dashboard, there is a new action under
> projects to allow downloading files:
> http://(server)/(ccnet)/server/(servername)/project/(projectname)/RetrieveFi
> le.aspx?file=(taskname)/(filename)&label=(label).
>
> The bad news, there is an issue with this on Win2K8 servers - it appears
> that IPSec is killing the file transfer process :-( We are looking into
> this, but haven't figured out how to fix it (yet).
>
> Craig
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
>
> Behalf Of CinnamonDonkey
> Sent: Saturday, 13 June 2009 12:54 a.m.
> To: ccnet-user
> Subject: [ccnet-user] Saving artifact files with a build
>
> Hi All,
>
> As part of my latest CC.NET adventure I have a build project which
> results in several artifact files of varying formats (*.pdf, *.pdb for
> example).
>
> I'd like to have these collated and accessable from the project build
> report page.
>
> It would be nice if each build had it's own folder in which build
> artifacts could be stored. It should then be possible to reference
> the contents of this folder from within XSL to add links so that the
> artifacts can be downloaded on the report page.
>
> Since CC.Net dosn't currently handle this. I'm experimenting to find a
> work around. I have tried creating a folder in the "artifacts
> \buildlogs" folder and placing some files inside of there. Then in my
> XSL template I am then trying to create a "right click and save as"
> type link for retrieving the file. But I can't seem to get the path
> right.
>
> Any idea what the path should look like?
>
> Cheers,
> Shaun
>
> p.s. I second the comment at the bottom of the "Merge Publisher"
> page...http://confluence.public.thoughtworks.org/display/CCNET/File+Merge+Task
