Presence of a TEAMCITY_PROJECT_NAME environment variable makes builds fail if TeamCity service unavailable #1570
Comments
|
To explain why it works this way, I'll have to go back in time, to 2015. :-) That's when @NikolayPianikov, a contributor for JetBrains, added the notion of a The class was used, in this case, to make the TeamCity option appear to be true, just as if you had entered the We'd like to keep this working for JetBrains users, so that limits what can be done for this issue without a bit of coordination. Before we go further, can you explain your use case? Why do you want to run under TeamCity, but not use the TeamCity extension. I have limited contact with the JetBrains folks, but my understanding from back then was that their display of results would be broken if the teamcity extension were not intalled. Depending on how this discussion turns out, I'll either make a simple change to the wording of the message or I'll queue up a task to revise how we handle options in general. Currently, the runner simply gets settings, without knowing whether they came from the command-line or elsewhere. |
Sure, I kind of expected that.
We have a project which is a mix of C++/C#/Matlab/Python/Installshield/.. and want our build/test/deploy to be a one-click kind of thing which can easily run anywhere. As such there's a single msbuild target which does everything, and that happens to include running nunit3-console just like it runs the other non-.Net tests via commandline commands. So CI builds are no different and also run that single msbuild command and we don't use any test integrations. Makes things easier to setup and maintain and avoids some of the 'does(n't) work on CI but does(n't) work locally' type of issues. |
With release 3.19.0 in, this commit leads to TeamCity CI builds failing for us with
Option --teamcity specified but the extension is not installed.even though we do not specify this option and we do not use any of TeamCity's nunit-related features: we just happen to use nunit3-console to run tests.nunit3-console --noheader --noresult /path/to/tests.dllCan be reproduced easily by setting a non-empty
TEAMCITY_PROJECT_NAMEenvironment variable.So:
--teamcityis specified even though that is not the case, which is a bit confusingTEAMCITY_PROJECT_NAMEenvironment variable as running under TeamCity. While correct, it also treats that as 'must use TeamCity extension', but that is for us not the caseI'd suggest that either the behavior is reverted, or modified to show a warning instead of an error (perhaps with a modified message stating 'TeamCity detected' or similar), or else made such that the user needs to explicitly request the TeamCity functionality (so by passing
--teamcityor by another environment variable).The text was updated successfully, but these errors were encountered: