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.

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

Allow vendor_path to be configured #544

Closed
wants to merge 7 commits into from

Conversation

jnraine
Copy link
Contributor

@jnraine jnraine commented Jun 10, 2019

Goal

By default, lines within vendor/ or .bundle/ are consider “out of project”. This is a good default for most Rails projects but there are other directories we’d also like to ignore. For example, patches to gems or the framework. If left as “in project”, these lines cause multiple issues to be grouped together because the first line in the stacktrace always points to the same patch line.

Right now, we’ve side stepped this by reaching into the gem and redefining Bugsnag::Stacktrace::VENDOR_PATH but it would be wonderful if this was a configurable option like any other.

Changeset

Added

vendor_path can now be configured.

This allows developers to set the vendor path regular expression, used to determine whether or not a line in the stacktrace appears in the project stacktrace or the full trace.

Bugsnag.configure do |config|
  config.vendor_path = /(^(vendor\/|\.bundle\/|extensions\/))/
end

Tests

  • Test for the configuration setter and getter were added.
  • Tests to ensure the new configuration option was respected was added for Bugsnag::Stacktrace.

Discussion

Outstanding Questions

Should the name of the configuration option be changed? Instead of vendor_path, perhaps project_file_pattern or similar.

Review

For the submitter, initial self-review:

  • Commented on code changes inline explain the reasoning behind the approach n/a
  • Reviewed the test cases added for completeness and possible points for discussion
  • A changelog entry was added for the goal of this pull request
  • Check the scope of the changeset - is everything in the diff required for the pull request?
  • This pull request is ready for:
    • Initial review of the intended approach, not yet feature complete
    • Structural review of the classes, functions, and properties modified
    • Final review

For the pull request reviewer(s), this changeset has been reviewed for:

  • Consistency across platforms for structures or concepts added or modified
  • Consistency between the changeset and the goal stated above
  • Internal consistency with the rest of the library - is there any overlap between existing interfaces and any which have been added?
  • Usage friction - is the proposed change in usage cumbersome or complicated?
  • Performance and complexity - are there any cases of unexpected O(n^3) when iterating, recursing, flat mapping, etc?
  • Concurrency concerns - if components are accessed asynchronously, what issues will arise
  • Thoroughness of added tests and any missing edge cases
  • Idiomatic use of the language

This allows developers to set the vendor path regular expression, used to determine whether or not a line in the stacktrace appears in the project stacktrace or the full trace.

```ruby
Bugsnag.configure do |config|
  config.vendor_path = /(^(vendor\/|\.bundle\/|extensions\/|private_gems\/))/
end
```

By default, lines within `vendor/` or `.bundle/` are consider “out of project”. This is a good default for most Rails projects but there are other directories we’d also like to ignore. For example, patches to gems or the framework. If left as “in project”, these lines cause multiple issues to be grouped together because the first line in the stacktrace always points to the same patch line.

Right now, we’ve side stepped this by reaching into the gem and redefining `Bugsnag::Stacktrace::VENDOR_PATH` but it would be wonderful if this was a configurable option like any other.
@jnraine jnraine marked this pull request as ready for review June 10, 2019 15:19
@jnraine
Copy link
Contributor Author

jnraine commented Jun 10, 2019

CI failure seems unrelated to this changeset:

$ bundle _${BUNDLE_VERSION}_ install --with "$GEMSETS" --binstubs
Fetching https://github.com/bugsnag/maze-runner
Fetching gem metadata from https://rubygems.org/..........
Fetching version metadata from https://rubygems.org/...
Fetching dependency metadata from https://rubygems.org/..
Resolving dependencies....
Installing rake 12.3.2
Installing concurrent-ruby 1.1.5
Installing minitest 5.11.3
Installing thread_safe 0.3.6
Installing addressable 2.3.8
Installing coderay 1.1.2
Installing connection_pool 2.2.2
Installing safe_yaml 1.0.5
Installing diff-lcs 1.3
Installing hashdiff 0.4.0
Installing method_source 0.9.2
Installing rack 2.0.7
Installing rdoc 5.1.0
Installing redis 4.1.2                                    -----
Gem::InstallError: redis requires Ruby version >= 2.3.0. <----- redis 4.1.2 doesn't work with Ruby 2.2
Installing rspec-support 3.8.0                            -----
Using bundler 1.12.0
Installing i18n 1.4.0
Using bugsnag 6.11.1 from source at `.`
Installing tzinfo 1.2.5
Installing crack 0.4.3
Installing pry 0.12.2
Installing rack-protection 2.0.5
An error occurred while installing redis (4.1.2), and Bundler cannot continue.
Make sure that `gem install redis -v '4.1.2'` succeeds before bundling.
The command "bundle _${BUNDLE_VERSION}_ install --with "$GEMSETS" --binstubs" failed and exited with 5 during .

The last time master was built, it used redis 4.1.1. Since then redis 4.1.2 has been released, which explictly drops support for Ruby 2.2.

@tobyhs tobyhs changed the base branch from master to next June 11, 2019 23:41
@tobyhs tobyhs changed the base branch from next to master June 11, 2019 23:41
@tobyhs
Copy link
Contributor

tobyhs commented Jun 11, 2019

I fixed the Ruby 2.2 + redis gem issue in #546 so you can merge master into your branch to fix it if you want. However, new features go into the next branch, so you might want to wait until that branch is brought up to date and then we'll try switching the base branch of this pull request to next.

@@ -63,6 +63,10 @@ class Configuration
# @return [Integer] the maximum allowable amount of breadcrumbs per thread
attr_reader :max_breadcrumbs

##
# @return [Regexp] matching file paths within the project
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if an @return comment makes sense for an attr_writer.

However, you can change the next line to attr_accessor (so an @return comment would be fine), and in #initialize set @vendor_path to the default regular expression.

##
# Regex used to mark stacktrace lines as within the project. Lines marked
# as "out of project" will only appear in the full trace.
def vendor_path
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add an @return comment (or not if you choose to use attr_accessor instead and set it to the default in initialize)

# Regex used to mark stacktrace lines as within the project. Lines marked
# as "out of project" will only appear in the full trace.
def vendor_path
@vendor_path || Bugsnag::Stacktrace::VENDOR_PATH
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider moving/renaming Bugsnag::Stacktrace::VENDOR_PATH to Bugsnag::Configuration::DEFAULT_VENDOR_PATH, as it is now a default, and it might be easier for users to find/discover this constant in Bugsnag::Configuration in case they need to use this regular expression to add to it for a new vendor path regular expression (maybe using something like Regexp.union).

@@ -396,4 +396,15 @@ def debug(name, &block)
expect(second_array).to eq([1, 2])
end
end

describe "vendor_path" do
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#vendor_path (with the # since it is an instance method)

@@ -87,4 +87,43 @@
})
}
end

describe "#vendor_cache" do
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand this doc string, as there isn't a vendor_cache instance method, and the tests don't appear to be related to caching.

@@ -396,4 +396,15 @@ def debug(name, &block)
expect(second_array).to eq([1, 2])
end
end

describe "vendor_path" do
it "should have the default vendor path" do
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer to avoid "should" in doc strings (https://github.com/rubocop-hq/rspec-style-guide#should-in-example-docstrings), mainly to avoid repeating it a lot (similar comment for line 405)

CHANGELOG.md Outdated

### Enhancements

* Add option to configure what file paths are included in the project stacktrace (`vendor_path`)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't seem clear, as all the file paths are usually included in the stacktrace. I would reword this to something like "Add option (vendor_path) to adjust filename matching for marking stackframes as in-project".

@tobyhs tobyhs changed the base branch from master to next June 17, 2019 17:10
@tobyhs
Copy link
Contributor

tobyhs commented Jun 17, 2019

I updated the next branch and changed the base branch of this pull request to next. @jnraine Can you update this when you get the chance?

@rafaelfranca
Copy link
Contributor

This option was present in 5.5 and was removed without giving any reason. #253. It used to allow arrays, and I believe it still should since you can have more than 1 vendor path.

@jnraine
Copy link
Contributor Author

jnraine commented Aug 9, 2019

@tedyangx / @mctaylorpants, can you take this to completion? It'll let you drop a monkey patch from the codebase. 😄

@mctaylorpants
Copy link

@jnraine yep we can take a look! Are you able to give us write access to your fork?

@jnraine
Copy link
Contributor Author

jnraine commented Aug 16, 2019

@mctaylorpants Done! Thanks for taking a look.

tedyangx and others added 4 commits January 24, 2020 14:54
…uration (and rename it to DEFAULT_VENDOR_PATH). 2. Add `attr_accessor :vendor_path` to Bugsnag::Configuration and initialize it with DEFAULT_VENDOR_PATH.
@tedyangx
Copy link
Contributor

@tobyhs @tomlongridge I have addressed the review comments and updated the pull request. Much appreciated if you can review this. Thanks!

@tobyhs
Copy link
Contributor

tobyhs commented Jan 26, 2020

@tedyangx : I no longer work at Bugsnag, so I won't be able to merge this.

@tomlongridge
Copy link
Contributor

Thank @tedyangx - we'll take a look.

@tomlongridge tomlongridge mentioned this pull request Jan 28, 2020
15 tasks
@tomlongridge
Copy link
Contributor

Raised separate PR with these changes - #583 - to enable CI to run.

@tomlongridge
Copy link
Contributor

@tedyangx / @jnraine - thanks for your contributions on this 🙏 The feature has now been released on 6.13.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants