StoryQ_Report ends up in a strange place on the build server

Jan 22, 2010 at 1:32 PM

Hi,

First of all, I think that StoryQ v.2 is great.

Not the least because my two patches (overarching story report, and full exception messages) are implemented ;-) (but in a much cleverer way than I did).

I'm not sure this is a StoryQ problem, but anyway, here it goes.

I get the nice report (StoryQ.xml) in the folder StoryQ_Report in the output folder when I run the stories from TestDriven.Net + NUnit 2.5.3.

When I run the stories on my build server (TeamCity 5.0, currently on the very same machine since its just a trial for the company as of now), the StoryQ_Report is created in a very strange place, far from the output directory.

I don't know the exact inner working of Directory.CreateDirectory() (which is used by StoryQ), but maybe somebody else knows what's going on here?

/Martin

Coordinator
Jan 22, 2010 at 2:52 PM

Hi Martin

Thanks! It's really nice to hear someone say nice things about this release, I put a lot of time into it but I broke a lot of backward compatiblity :D

I'm currently working on documentation, and this page (which is juuust about finished): http://storyq.codeplex.com/wikipage?title=write%20your%20first%20StoryQ%20test might have been the one to help you out here, had I written it in time.

Right at the bottom I explain:

After executing this test, StoryQ will write the report to "CurrentDirectory\StoryQ_Report\StoryQ.xml". If you want know what directory your test runner treats as current, put Console.WriteLine(Environment.CurrentDirectory); at the top of your test and re-run it.

So it's basically outputting the the process's current directory. This also causes strange behaviour when using the built in NUnit runner, although MSTest and Resharper runners behave well.

As for TeamCity, I think you can overide the Working directory at the project level in the project's settings.

 

 

I was toying with the idea of allowing you to pass the output directory into the ExecuteWithSimpleReport method. Do you think that's a good idea? Or its it likely to change from machine to machine, so it should instead pick up the output directory from environment variables or settings. Hmmmmmm.

Anyway, let me know if you could change the "Current" directory for TeamCity satisfactorily

Jan 25, 2010 at 12:05 PM

It's really the strangest thing...

Running NUnit from TD.NET from within VS:

 

C:\BuildAgent\work\5be4573062d36976\trunk\code\output
C:\BuildAgent\work\5be4573062d36976\trunk\build scripts\StoryQ_Report
C:\SVN\Back Office Synchronizer 2\trunk\code\output
C:\SVN\Back Office Synchronizer 2\trunk\code\output\StoryQ_Report

Environment.CurrentDirectory: C:\SVN\MyProject\trunk\code\output

StoryQ_Report directory: C:\SVN\MyProject\trunk\code\output\StoryQ_Report

 

Running NUnit from TeamCity:

Environment.CurrentDirectory: C:\BuildAgent\work\5be4573062d36976\trunk\code\output (so it's not a TeamCity work dir problem)

StoryQ_Report directory: C:\BuildAgent\work\5be4573062d36976\trunk\build scripts\StoryQ_Report

 

I've previously heard about Path.Combine (which gets used by SimpleHtmlFileManager) problems, but investigating the matter (e.g. http://stackoverflow.com/questions/53102/why-does-path-combine-not-properly-concatenate-filenames-that-start-with-path-dir) doesn't help the case either. 

 

I also tried using System.IO.Path.GetDirectoryName(typeof(DummyStoryFixture).Assembly.Location), but that yielded the same results.

 

For now, I'm using the hacky solution to just point at the "build scripts" folder as the artifacts folder in TeamCity, but it's really bad for maintainability and readability. As I said before, I'm in doubt whether this is a StoryQ problem, but the previous version outputs the html files, one for each story, just fine in the output dir on the build server, and so does log4net as of now.

 

Whether to supply possibilities for defining the output dir or not... I think that's a good idea. If you want to save yourself from overload(s), wait for C#4 and optional params.

 

Thanks a lot for trying to help out!

/Martin

 

 

 

 

Coordinator
Jan 25, 2010 at 1:12 PM

Hi Martin

I think I know what might be going on here - i hope you've got time to help me test it.

if you update SimpleHtmlFileManager to the following, I think this issue might get fixed:

 

internal static class SimpleHtmlFileManager
    {
        private static XmlCategoriser instance;

        private const string StyleSheetFileName = "StoryQ-SimpleHtml.xslt";

        public static XmlCategoriser AutoSavingCategoriser
        {
            get
            {
                if (instance == null)
                {
                    string stylesheet = string.Format("href=\"{0}\" type=\"text/xsl\"", StyleSheetFileName);
                    XDocument doc = new XDocument(
                            new XProcessingInstruction("xml-stylesheet", stylesheet),
                            new XElement("StoryQRun"/*, new XAttribute("Started", DateTime.Now.ToString())*/));

                    // record full path info NOW - not reliable during DomainUnload
                    DirectoryInfo outputDir = new DirectoryInfo("StoryQ_Report");
                    outputDir.Create();
                    string fullPath = outputDir.FullName;
                    

                    AppDomain.CurrentDomain.DomainUnload += (sender, args) =>
                        {
                            //save the xml
                            doc.Save(Path.Combine(fullPath, "StoryQ.xml"));
                            //write out the xslt
                            File.WriteAllText(Path.Combine(fullPath, StyleSheetFileName), SimpleHtmlDependencies.SimpleHtml, Encoding.UTF8);
                        };
      
                    instance = new XmlCategoriser(doc.Root);
                }
                return instance;
            }
        }
    }

 

If you'd prefer a DLL, let me know and i'll find somewhere to attach it

 

Coordinator
Jan 25, 2010 at 1:16 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.