Open mausch opened 12 years ago
Or generate NUnit-style XML output.
:+1:
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?
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 :)
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.
After a few minutes of looking at this I have a couple thoughts.
defaultMainThisAssemblly
etc, but rather just to be able to pass another command-line argument to it.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?
+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 :)
Okay, thanks for the input, that's very helpful! I'll see if I can work on this on Saturday.
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
?
/teamcity
sounds good to me. I kinda regret now using Windows-style args, but that's a different discussion :)
Is it important to maintain the API of all public functions? or just at the level of run
/runParallel
?
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.
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.
flowId
and the interaction of parallel with TeamCityFuchu.TeamCity
and its dependenciesThe 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.
Hm, rats. What a weird thing to be stuck on.
Use https://github.com/JetBrains/TeamCity.ServiceMessages