Update NuGet Package

[getsentry]

Update NuGet Package

[dcramer]

I'm about to get on a plane and for the life of me can't remember anything of how we set this up (also can't seem to login to the TeamCity system beyond guest, assuming I really actually had an account :)

Can anyone confirm if we actually require a windows box for building the nuget packages? Otherwise I'm happy to setup a public Jenkins instance for the mono build/etc within getsentry.com's infrastructure.

[asbjornu]

Hey. I've configured the TeamCity build to have a build configuration we can run manually to push out a new NuGet package. As the build is currently not passing (1 failing test), I wouldn't push out a new NuGet package before investigating what the problem might be.

[dcramer]

I quickly looked at the build. Looks like it's actually pinging Sentry? Or is the build setup just to send errors to a Sentry instance?

[asbjornu]

Yea, the client is currently written in a way that makes it hard to fully test it without also doing HTTP requests to Sentry. Which is very unfortunate, but making testing easier is not something I have been able to prioritize yet.

[asbjornu]

It would be nice to have an endpoint that acted almost like /dev/null in that it received and responded appropriately, but didn't actually store anything. This endpoint should only be used for testing and be without any rate limits. Would that be possible to set up? I'll get it in and will get out a new NuGet package as soon as that exists, unless it takes days to get it set up. What do you think, @dcramer?

[mattrobenolt]

@asbjornu We could add one... but I'm not sure why it needs to actually hit an external source during testing? Normally that's a thing you would mock. Not sure how something like that works in C# though or I'd give a better recommendation. :)

If you want a black hole for some reason, you can just hit like, https://httpbin.org/post or something which will just echo what you send back.

[asbjornu]

@mattrobenolt Having an integration test that ensures that the HTTP part of the library actually works (like when you decide to turn off SSL3 support or something similar 😄) is very valuable. While I agree that it definitely should be possible to mock the HTTP part of the client, that's not how the client is currently written and it requires a large rewrite to implement it.

While httpbin could work, it does not reply with the expected response, which should be JSON containing the GUID of the created event. A complete integration test needs to test the actual endpoint, not something similar, but different.

[mattrobenolt]

@asbjornu I'm going to have to kindly and strongly disagree with that perspective.

Out of all the clients we have, not one that I'm aware of hits our servers during automated tests. That is extremely fragile.

In the case of explicitly testing SSLv3 and whatnot, that is such an extreme edge case and technically has no real relationship with the clients since the clients can talk to other servers as well. Not just app.getsentry.com. You may host your own, or even write your own Sentry and use the client for that. I also assure you there are more edge cases that wouldn't be covered by tests that are easier to break compatibility than turning off SSLv3. 😉

So with that said, it's not really in our interest to add an endpoint into Sentry for the sole purpose of facilitating people running automated testing against.

I'm not sure of the resolution here, but in the interim can we possibly remove the tests which are failing, or test them manually by hand as to not hit the 429 rate limiting to make sure that everything is fine before publishing a new release?

[dcramer]

I was considering adding a validation endpoint, but I dont really like that idea either

[asbjornu]

While I disagree with you on the usefulness of a full integration test, I agree that it shouldn't be automated. I'd love to have such a test in place that I can run manually before creating a new NuGet package, just to be sure everything is in working order. Right now, CodeBetter's TeamCity server is down for maintenance, but as soon as it's up again, I'll push out a new NuGet package.

[asbjornu]

@mattrobenolt @dcramer Another thing that is very useful to test by integrating the real Sentry back-end is compression. This is an area of SharpRaven that didn't work when I started developing on the project, but that is working now only because I've tested it against the real back-end. I'm not saying the tests that verify this needs to run automatically, I'm just trying to convince you the usefulness of having full integration testing in place somehow, somewhere. 😄

[asbjornu]

There. Version 1.4.0.54 is up on NuGet.