Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stop Bundling the TeamCity Extension #878

Closed
CharliePoole opened this issue Jan 26, 2021 · 6 comments · Fixed by #1143
Closed

Stop Bundling the TeamCity Extension #878

CharliePoole opened this issue Jan 26, 2021 · 6 comments · Fixed by #1143
Assignees
Milestone

Comments

@CharliePoole
Copy link
Collaborator

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.

@ChrisMaddock
Copy link
Member

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.

@CharliePoole
Copy link
Collaborator Author

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.

@mikkelbu
Copy link
Member

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

@ChrisMaddock
Copy link
Member

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.

@mikkelbu
Copy link
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.

@CharliePoole
Copy link
Collaborator Author

#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.

@CharliePoole CharliePoole changed the title Stop Distributing the TeamCity Extension Stop Bundling the TeamCity Extension Jan 13, 2022
@CharliePoole CharliePoole self-assigned this Feb 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants