Skip to content

Stop Bundling the TeamCity Extension #878

Closed

Description

@CharliePoole

We've talked about this in the past but I can't find an existing issue for it.

It seems to me that V4.0 is a reasonable point for us to stop distributing the TeamCity extension in the Msi. Jetbrains can make the extension available on nuget and chocolatey and provide instructions as to how to add it to an msi installation - we can even help with the last - but as previously decided, we should stop distributing an extension for a particular CI solution when we don't do that for any others.

Activity

  1. added this to the 4.0 milestone on Jan 26, 2021
  2. ChrisMaddock commented on Jan 27, 2021

    @ChrisMaddock
    Contributor

    I think this will be one of the more controversial changes proposed - due to the number of users disrupted and the commercial concerns of JetBrains.

    I don't disagree it would be the right approach if we were adding the TeamCity package now, but I do wonder if the benefits justify the disruption to users here in making the breaking change. I like to think more about this one, interested in what others think.

  3. CharliePoole commented on Feb 28, 2021

    @CharliePoole
    MemberAuthor

    Should note that the console runner actually has a special option for enabling the teamcity extension.

    IMO this would be a great opportunity to introduce an open way of enabling/disabling extensions by name on the command-line. We could use something like --enable <extension> or maybe --require <extension>, giving an error if the extension is not installed.

  4. mikkelbu commented on Feb 28, 2021

    @mikkelbu
    Member

    I like the idea of a more general solution than the hardcoded solution for teamcity - --teamcity as discussed in #441.

  5. ChrisMaddock commented on Feb 28, 2021

    @ChrisMaddock
    Contributor

    Did you mean #148 by any chance Mikkel? I was going to say the same. 🙂

    Have thought about this more. Personally, I think this is another issue which doesn't have enough benefit to justify the inconvenience to users of the breaking change. Packaging the TC extension is essentially zero-cost, when we're already doing it for 4 other extensions. I think if any new CI provider was to approach us and ask for their extension to be included we would decline, but we should instead view this as a historic misjudgement which we maintain for backwards compatibility. So continue to package the extension.

    It would be nice to get rid of the --teamcity flag through something like #148. That's another chunky feature to include in v4 however, and I'm not sure it's a priority.

    Interested in what others think here.

  6. mikkelbu commented on Mar 13, 2021

    @mikkelbu
    Member

    Did you mean #148 by any chance Mikkel? I was going to say the same. 🙂

    No. #441 contains the following comment (among other)

    Edit edit: If there were a general way to enable/disable extensions on the command line (like the hardcoded one for --teamcity), @CharliePoole's declarative approach would be fine also. Don't we want such a feature? Shouldn't be hard to do, I think.

  7. CharliePoole commented on Mar 13, 2021

    @CharliePoole
    MemberAuthor

    #441 is more about the start-run count being zero. I just added a comment about that but we need to look further to fix it.

    The comment @mikkelbu is referring to is actually more related to #148, although it came up in #441.

  8. changed the title [-]Stop Distributing the TeamCity Extension[/-] [+]Stop Bundling the TeamCity Extension[/+] on Jan 13, 2022
  9. self-assigned this
    on Feb 18, 2022
  10. modified the milestones: 4.0, 4.0.0-beta.1 on Dec 29, 2024
  11. added
    V4All issues related to V4 or later - use -label:V4 to get V3 issues
    on Feb 1, 2025
  12. CharliePoole commented on Jun 21, 2025

    @CharliePoole
    MemberAuthor

    In addition to unbundling the extension, the console option --teamcity is now removed. In its place, use --enable NUnit.Engine.Listeners.TeamCityEventListener.

  13. CharliePoole commented on Jun 26, 2025

    @CharliePoole
    MemberAuthor

    This issue has been resolved in version 4.0.0-beta.1

    The release is available on:
    GitHub.
    NuGet packages are also available NuGet.org and
    Chocolatey Packages may be found at Chocolatey.org

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Breaking ChangeV4All issues related to V4 or later - use -label:V4 to get V3 issues

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions