search

cake-build / cake

:cake: Cake (C# Make) is a cross platform build automation system.
https://cakebuild.net
MIT License
3.91k stars 729 forks source link

Add BuildStatisticValue method to TeamCityProvider #1431

Open marekgd opened 7 years ago

marekgd commented 7 years ago

or make WriteServiceMessage method public in TeamCityProvider so we can send any message to TeamCity

aateeque commented 7 years ago

ITeamCityProvider already provides several constructs to speak to TeamCity. Can you share example & details of what BuildStatisticValue will do?

marekgd commented 7 years ago

This is needed to integrate Code Coverage report - OpenCover http://www.fabienruffin.com/integrating-opencover-test-coverage-statistics-with-teamcity/

kcamp commented 7 years ago

@devlead Any thoughts on this? I also have a need to extend the support of the ITeamCityProvider to support the service messages surrounding tests (testStarted, testFinished, testFailed, etc.)

I've started down the road of implementing extension methods, but the real sticking point is that the WriteServiceMessage(string message, Dictionary<string, string> values) method isn't exposed, nor is the ICakeLog on a given ITeamCityProvider instance. Here is a very rough idea of the direction in which I am headed (and the limitations of it), for reference -- 707bac3af

As was mentioned, if we can expose the generic WriteServiceMessage method somehow, that would go a long way in letting any consumer write any messages, but it would be a breaking change for the ITeamCityProvider interface, so I don't know if that's an option at this point.

To avoid the breaking change, we could also create a new interface that represents the superset of all TC related functionality, have TeamCityProvider implement that interface, and then add a TeamCity2 property (or method?) to the BuildSystem class, which should prove workable, given that the BuildSystem class is sealed and implements/inherits no abstractions. I put together a quick POC of this (minus tests, but it should be representative) that can be seen at b258a720a. This solution would largely negate the refactoring done in the previously referenced commit, but I've left it intact for now.

Thoughts? Not being able to utilize the full spread of TeamCity service messages is definitely limiting, it would be helpful to have this functionality. I am happy to continue with this work & create a PR if there's a direction we can agree on. Thanks!