nunit / teamcity-event-listener

NUnit Engine extension that helps integration with teamcity
MIT License
11 stars 10 forks source link

Add possiblity to turn off TeamCity message publishing #2

Open CharliePoole opened 8 years ago

CharliePoole commented 8 years ago

@martinskuta commented on Fri Apr 29 2016

Currently we have an issue #1432 that our build gets stuck (most probably due to reporting to Teamcity) so as a workaround we tried to turn it off, but it seems there is no way on our TC agent.

We were passing --teamcity to enable the reporting, then we encountered the issue, so we tried to remove the flag thinking it will disable the reporting to teamcity, but it turns out it is always on.

Looking at code it is because of DefaultOptionsProvider (link) which will set it to true if enviroment variable TEAMCITY_PROJECT_NAME is defined, which is always defined on team city agent during build afaik.

Would be nice to have a possibility to turn that off.


@martinskuta commented on Fri Apr 29 2016

Basically this the problem expressed in test.. if you don't pass the --teamcity argument it is true anyway.

        [Test]
        public void IsTeamCity_ArgumentNotSpecified_ExpectFalse()
        {
            //this will fail on TeamCity agent during build, because of implementation of DefaultOptionsProvider which returns True for TeamCity during TC build
            var options = new ConsoleOptions(new DefaultOptionsProvider(), "--version");
            Assert.IsFalse(options.TeamCity);

            //this is reproduced behavior with stub
            options = new ConsoleOptions(new DefaultOptionsProviderStub(true), "--version");
            Assert.IsFalse(options.TeamCity); //Is true, eventhough we didn't pass --teamcity
        }

Paste the test to NUnit.ConsoleRunner.Tests.CommandLineTests


@rprouse commented on Fri Apr 29 2016

Added to backlog. I would like to get the opinion of the JetBrains people on this, but I am not against the idea. I don't like the fact that we have special behaviour for one CI system, but not all the others. It becomes a pretty slippery slope :smile:


@CharliePoole commented on Fri Apr 29 2016

It's not clear whether this applies to the console runner or nunitlite, but in fact we should do the same thing for both runners.


@martinskuta commented on Fri Apr 29 2016

@rprouse thank you for adding it to backlog. Yeah I would expect this functionality as a plugin, but nothing is perfect :wink:

It's not clear whether this applies to the console runner or nunitlite

@CharliePoole at the moment the issue we have is with console runner, I dunno about nunitlite as we are not using it, but generally speaking should be same for every runner imho.


@NikolayPianikov commented on Tue May 03 2016

To turn off the integration with TeamCity you could add the environment variable "env.TEAMCITY_PROJECT_NAME" with empty value to your build configuration or build project.


@vgriph commented on Tue May 03 2016

A possible work-around (or bug?) is to specify an output file in which case the TeamCity status messages will be written to that file and not be picked up by TeamCity.


@CharliePoole commented on Wed May 25 2016

@vgriph Unfortunately, your workaround was a bug. It's now fixed in master.


@martinskuta commented on Tue May 31 2016

@NikolayPianikov Setting the env. variable TEAMCITY_PROJECT_NAME to empty string works, but it feels a bit strange, because I was not sure if someone is not using that environment variable. I was mainly confused by the --teamcity argument naming, because that's what I thought is enabling the TC reporting in general, not enabling it only if it is not already enabled for debugging purposes :).

I cannot really think of any good solution for this issue without introducing breaking changes, which none of us want so I feel like we can close this one.


@CharliePoole commented on Tue May 31 2016

Please don't close this... as you can see (on GitHub) it is already listed in our backlog as a planned enhancement. Most likely, we will do something like --noteamcity on the command-line.

In fact, I accepted it as an enhancement because the workaround didn't appeal to me either. :-)