Hacker News Reader

Comment by orose_ | Hacker News Reader

It's somewhat ironic that a monitoring service has shit the bed. For some reason at work we're using Webpack, and, for some reason we are also using Sentry Webpack plugin that is causing our whole CI to fail.

This is fine.

View on HN

Maybe it's just me, but I feel like monitoring software failures should not cause application failures.

It’s likely that the failure is around Sentry’s “signal a release and upload your source code out of band to us” feature.

In theory things shouldn’t break but if your CI process involves signaling a third party, it can fail from that (hopefully you can temporarily disable it or something of the sort)

Yes the CI should fail, or else you would be deploying something that can't match your errors to your source code (via the sourcemaps which is what presumably gets uploaded to sentry on the CI run).

Take in advance that I don't know Sentry, nor webpack et al but, in my mind, I'd like to have an opportunity to continue my build process with a big, red warning.

I prefer a 98% accurate error reporting better than a 100% one I can't push to production.

Or maybe I'm not understanding well the value Sentry offers, of course.

It can be desired to continue on failure, the tradeoff is that there is then a release out there with lacking error-sourcecode mapping.

I think if your release cycle is longer, then you will prefer not to deploy without sourcemaps.

I kind of agree. Their source map thing to get better traces is a nicety, but few would find it release blocking to forgo it

Edit due to other comment: this assumes CI/CD. If you were deploying only weekly then this might be good reason to delay

This is a choice, usually hidden until you stumble upon it. Is Sentry being available, (actually, the ability to upload sourcemaps) that important for you to fail a CI or you can just fire up a warning somewhere?

Reply on news.ycombinator.com