TeamCity Mode cannot be turned off

[BlythMeister]

When you do not pass the --teamcity argument NUnit console still detects that it's running on teamcity and sends the service messages.

This makes the --teamcity parameter pointless (unless you want services messages when not on teamcity)

How can i stop the teamcity service messages from being written to the console.

[mikkelbu]

As far as I can tell the only way to stop the messages from being written is to "undeclare" the environment variable TEAMCITY_PROJECT_NAME, e.g. removing it - or setting it to the empty string - before calling the console. Why the behaviour is like this I don't know.

nunit-console/src/NUnitConsole/nunit3-console/DefaultOptionsProvider.cs

Lines 29 to 37 in f98bd13

	private const string EnvironmentVariableTeamcityProjectName = "TEAMCITY_PROJECT_NAME";
	public bool TeamCity
	{
	get
	{
	return !string.IsNullOrEmpty(Environment.GetEnvironmentVariable(EnvironmentVariableTeamcityProjectName));
	}
	}

[BlythMeister]

Yeah, my current workaround in my fake script is to grab the environment variable, set to empty, call nunit, set value back after.
Just feels a bit...well...dirty.

And very much like a bug (or accidental feature)

[CharliePoole]

IIRC the current behavior was requested by the TeamCity folks.

[ChrisMaddock]

@NikolayPianikov - can you help with this one? 🙂

[BlythMeister]

I essentially get 2 reports of tests.
1 from the console and 1 from the imported XML.

[CharliePoole]

Unfortunately, none of us who worked on the nunit side of this are users of teamcity. Our understanding from the JetBrains folks was that their integration of test status could only work through the special messages. It sounds like you run under teamcity but don't actually want that integration. Is that the case?

[BlythMeister]

That is correct, I do not want TeamCity messages from the console.
Although I'm using TeamCity, I have my own build process.

[CharliePoole]

We would have to introduce an option like --teamcity:off and only use the environment variable if nothing was specified. What do people think about that?

[BlythMeister]

I like that, means I don't need to hack about with variables maybe "--no-teamcity" the same as no-restore on the dotnet cli?

[mikkelbu]

Personally, I find it a bit strange that we need to both have the option --teamcity and look for special environment variables to make it work in TeamCity. I would rather have that we had some general approach like #148 for adding custom options and then make these options available for the extensions.

[NikolayPianikov]

@BlythMeister The most simple way is to remove TeamCity extension from your NUnit bin directory or install NUnit via NUnit.ConsoleRunner and all required extensions without TeamCity

[CharliePoole]

@NikolayPianikov That would definitely do it. I guess I assumed they couldn't because of other applications.

[NikolayPianikov]

I could add an environment variable to forcibly turn off TeamCity reporting in the extension

[BlythMeister]

@NikolayPianikov Currently i use NUnit.Console
But i like the idea of just doing all the bits manually :)
I guess, i need to work out which of the standard extensions are required :D

[NikolayPianikov]

@BlythMeister Most of them are quite obvious like NUnit.Extension.NUnitV2Driver, but
you could start from the scratch and to add them sequentially, until everything will work as expected.

[CharliePoole]

@BlythMeister As follows (all prefixed with NUnit.Extension.):

NUnitV2Driver if you run NUnit V2 tests
NUnitV2ResulWriter if you want reports in V2 XML format rather than V3.
NUnitProjectLoader if you use .nunit projects on the command-line (or if TeamCity does it for you).
VSProjectLoader if you use .csproj or .sln files on the command-line

[CharliePoole]

@NikolayPianikov The general idea with extensions is that once they are installed and enabled by the runner, they do there job. IOW "policy" decisions about whether to use the extension are made at a higher level. In any case, in practice, it would be messy if the extension were self-enabling/disabling in addition to having it done by the runner through the engine API. You could end up with a race.

[CharliePoole]

@mikkelbu I agree entirely. We implemented it first as an option but then got the request for allowing the environment variable to turn it on as well as a way of making it easier for users. It probably does for most users, but it ain't pretty. 😄

Issue #148 as discussed ended up dealing with allowing extensions to access information the runner and engine already have. That's not necessary here, first because the engine doesn't have the info (i.e. user really doesn't want to enable teamcity extensions under teamcity) and second because it doesn't really need that info because it's the runner's job to enable / disable the extension for whatever reason.

I do think we need a more general way to add command-line arguments, by first allowing the console to define extension points and second by creating an option interpreter extension point. That's kind of big, however. 😸

[BlythMeister]

I actually think this is a solved problem.
The way to turn off the teamcity messages is to not have the extension in place.

This is my mistake. I'm happy for this issue to be closed.

For my use case, i didn't actually need any of the extensions!