TeamCity integration

[mausch]

Use https://github.com/JetBrains/TeamCity.ServiceMessages

[mausch]

Or generate NUnit-style XML output.

[Kazark]

👍

[Kazark]

I have an interest in implementing this. I saw you said you were getting frustrated with the TeamCity.ServiceMessages library. There isn't much to TeamCity messages; I don't think we would need a library. You can literally just write a line of text out to the console.

If I implemented it with that approach, would you be interested to merge it in?

[mausch]

Yeah, I agree it's not worth messing around with that library, instead just writing the special messages as strings to console. I'd love to merge such a feature of course :)

[Kazark]

Okay I'm going to take a look at this for an hour or so this morning, and maybe I can give a little time to it on Saturday. I would be really pumped to get this working.

[Kazark]

After a few minutes of looking at this I have a couple thoughts.

1. If we aren't bringing in any new dependencies for it, I'm not sure there's a reason to put this in its own assembly, i.e. if all I'm doing is writing text the console, seems like we could just have it right in the main Fuchu DLL.
2. It would be nice not have to reimplement defaultMainThisAssemblly etc, but rather just to be able to pass another command-line argument to it.
3. Similarly, it would be nice to not have this as an alternative to running parallel, but to be able to compose the two things together (though perhaps that is unrealistic).

So before I go any further, I'd like some feedback: am I going in the wrong direction if I remove Fuchu.TeamCity, and instead put the TeamCity runner straight into Fuchu itself and try to get it to play nicely in an integrated way with the rest of the stuff?

[mausch]

+1 for scrapping the Fuchu.TeamCity project.

As for command-line options, I'd model that as something like:

type TeamCityOutput = EnvVariable | ForceYes | ForceNo

then add that to RunOptions,
then alter parseArgs to parse that,
then interpret that in defaultMainWithOptions down to yes/no
etc :)

[Kazark]

Okay, thanks for the input, that's very helpful! I'll see if I can work on this on Saturday.

[Kazark]

I'm not familiar with Windows command-line conventions. I see you are using /m rather than -m. I was thinking of using --teamcity for the command-line argument, but that doesn't really fit with /m. What would fit here: /t? /teamcity?

[mausch]

/teamcity sounds good to me. I kinda regret now using Windows-style args, but that's a different discussion :)

[Kazark]

Is it important to maintain the API of all public functions? or just at the level of run/runParallel?

[Kazark]

So far, I have deliberated worked to maintain the API of run/runParallel, but haven't bothered to do so with evalSeq and evalPar. Let me know if you think I need to do it with those too.

[Kazark]

Alright, well I wasn't able to work on this on Saturday, but I did make solid progress on it this morning. Nothing ready yet; a lot of discovery work about Fuchu and how to interact it with TeamCity. I think this is going to be pretty doable though. The only major open question I have right now is how parallel tests is going to interact with TeamCity.

[Kazark]

• Research TeamCity service message flowId and the interaction of parallel with TeamCity
• Deal with environment variable idea
• Remove Fuchu.TeamCity and its dependencies
• Test command-line option versus environment variable
• Test without parallelism
• Test with parallelism
• Test ignored test
• Test passed test
• Test failed test

[Kazark]

The FAKE build isn't working on my machine, and I'm struggling to figure out why. Trying to generate a package for my local NuGet server so I can do some testing.

[Kazark]

Hm, rats. What a weird thing to be stuck on.