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.

Sign up for GitHub

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

Jump to bottom

chore: add missing changelog entry for 1.74.4 #1289

Merged
merged 1 commit into from
Jul 18, 2022
Merged

chore: add missing changelog entry for 1.74.4 #1289

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
105 changes: 56 additions & 49 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -47,55 +47,55 @@

### Source Maps Upload Check "y-tho" (ongoing)

*Problem statement:*
Uploading source maps is a common source of frustration. Source maps are also one of the great value adds to our in product experience. We want to automate supporting customers with frequent issues.
https://docs.sentry.io/platforms/javascript/sourcemaps/troubleshooting_js/
*Outcome: *
Developers will be provided with a tool to help them discover any issues they may have when uploading source maps
Sentry support will have a tool and docs to suggest to customers to hopefully first discover issues, and second at least know what their problem is NOT.
*Key measurements:*
* qualitative: Is this useful for customers and support
* quantitative: Can we try to influence the number of Zendesk tickets
* quantitative: Can we influence the resolution time of source maps related Zendesk tickets
Can we find a way to track in zendesk the number of times the sentry-cli “y-tho“ functionality was useful
*Additional*
This is something users would run locally so I do not think we can track usage exactly what was not covered in y-tho
* Verify your source maps are built correctly
* Verify your source maps work locally
* Verify your source files are not too large
* this is a fuzzy requirement today in sentry
* Verify artifacts are not gzipped
* Verify workers are sharing the same volume as web (if running self-hosted Sentry via Docker)
* Should spit out an easily readable and easily copy and paste - to put into ZenDesk or elsewhere for support colleagues
*Possible second milestone:*
https://github.com/getsentry/rust-sourcemap/tree/master/cli
* In sentry error incorrect source map location
* this helps when producing sourcemaps locally then line and column
* this verify that it resolves locally
* if yes then it is a problem in between on sentry server side or upload
* 1st Verifies what you upload to sentry is exactly what you upload to sentry
* 2nd step from “y-tho” ensure previous steps are not for waste
* What is being automated?
* on release page you have your files (release artificats)
* download
* manually check the line number matches the error
* if correct then data is correct
* then you know an error with cli and not with the source maps that were uploaded
*Problem statement:*

Uploading source maps is a common source of frustration. Source maps are also one of the great value adds to our in product experience. We want to automate supporting customers with frequent issues.

https://docs.sentry.io/platforms/javascript/sourcemaps/troubleshooting_js/

*Outcome: *

Developers will be provided with a tool to help them discover any issues they may have when uploading source maps

Sentry support will have a tool and docs to suggest to customers to hopefully first discover issues, and second at least know what their problem is NOT.

*Key measurements:*

* qualitative: Is this useful for customers and support
* quantitative: Can we try to influence the number of Zendesk tickets
* quantitative: Can we influence the resolution time of source maps related Zendesk tickets

Can we find a way to track in zendesk the number of times the sentry-cli “y-tho“ functionality was useful

*Additional*

This is something users would run locally so I do not think we can track usage exactly what was not covered in y-tho

* Verify your source maps are built correctly
* Verify your source maps work locally
* Verify your source files are not too large
* this is a fuzzy requirement today in sentry
* Verify artifacts are not gzipped
* Verify workers are sharing the same volume as web (if running self-hosted Sentry via Docker)
* Should spit out an easily readable and easily copy and paste - to put into ZenDesk or elsewhere for support colleagues

*Possible second milestone:*

https://github.com/getsentry/rust-sourcemap/tree/master/cli

* In sentry error incorrect source map location
* this helps when producing sourcemaps locally then line and column
* this verify that it resolves locally
* if yes then it is a problem in between on sentry server side or upload
* 1st Verifies what you upload to sentry is exactly what you upload to sentry
* 2nd step from “y-tho” ensure previous steps are not for waste
* What is being automated?
* on release page you have your files (release artificats)
* download
* manually check the line number matches the error
* if correct then data is correct
* then you know an error with cli and not with the source maps that were uploaded



By: @kamilogorek (#1235)
Expand Down Expand Up @@ -189,6 +189,13 @@ Breaking changes are denotated with _(breaking)_ tag, and appropriate required c
- ref: Make all `ProgressBar` instances and logs always write to `stderr`
- ref: Migrate error handling from `failure` to `anyhow` crate

## 1.74.4

### Various fixes & improvements

- ci: Add merge target (f9a2db3) by @kamilogorek
- ref: Prevent @vercel/nft and similar tools from including binary file in their bundles (#1207) by @kamilogorek

## 1.74.3

### Various fixes & improvements
Expand Down