5 ms·

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 Webp

by orose_ 4y ago

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.

bovermyer 4y ago
Maybe it's just me, but I feel like monitoring software failures should not cause application failures.
- rtpg 4y ago
  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)
  - the_gipsy 4y ago
    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).
    - luismedel 4y ago
      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.
      - the_gipsy 4y ago
        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.
      - np_tedious 4y ago
        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
CSDude 4y ago
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?

by orose_ 4y ago

bovermyer 4y ago

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

rtpg 4y ago
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)
- the_gipsy 4y ago
  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).
  - luismedel 4y ago
    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.
    - the_gipsy 4y ago
      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.
    - np_tedious 4y ago
      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

CSDude 4y ago

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?