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

Error reporter #261

Merged
merged 8 commits into from
Oct 10, 2017
Merged

Error reporter #261

merged 8 commits into from
Oct 10, 2017

Conversation

danielwelch
Copy link
Contributor

implementing pluggable error reporters, as discussed in #210.

I've proposed some implementations compatible with this for rollbar and sentry with some documentation available in each repository's README.md.

Includes documentation changes for configuring error reporters.

@danielwelch danielwelch mentioned this pull request Oct 3, 2017
@codecov-io
Copy link

Codecov Report

Merging #261 into master will decrease coverage by 2.71%.
The diff coverage is 43.47%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #261      +/-   ##
==========================================
- Coverage    93.2%   90.49%   -2.72%     
==========================================
  Files          41       41              
  Lines        2724     2735      +11     
==========================================
- Hits         2539     2475      -64     
- Misses        185      260      +75
Impacted Files Coverage Δ
django_q/conf.py 74.25% <38.88%> (-4.64%) ⬇️
django_q/cluster.py 91.34% <60%> (ø) ⬆️
django_q/brokers/ironmq.py 0% <0%> (-94.74%) ⬇️
django_q/tests/test_brokers.py 70.58% <0%> (-11.77%) ⬇️
django_q/brokers/__init__.py 94.18% <0%> (-2.33%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d33752f...cd038f6. Read the comment docs.

@codecov-io
Copy link

codecov-io commented Oct 3, 2017

Codecov Report

Merging #261 into master will decrease coverage by 2.96%.
The diff coverage is 40%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #261      +/-   ##
==========================================
- Coverage    93.2%   90.24%   -2.97%     
==========================================
  Files          41       41              
  Lines        2724     2748      +24     
==========================================
- Hits         2539     2480      -59     
- Misses        185      268      +83
Impacted Files Coverage Δ
django_q/conf.py 70.9% <35%> (-7.98%) ⬇️
django_q/cluster.py 90.95% <60%> (-0.4%) ⬇️
django_q/brokers/ironmq.py 0% <0%> (-94.74%) ⬇️
django_q/tests/test_brokers.py 70.58% <0%> (-11.77%) ⬇️
django_q/brokers/__init__.py 94.18% <0%> (-2.33%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d33752f...4530b05. Read the comment docs.

@joeyespo
Copy link

joeyespo commented Oct 4, 2017

This looks great! 👍

Copy link
Collaborator

@Eagllus Eagllus left a comment

Choose a reason for hiding this comment

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

I like the idea of this pull request but making breaking with deprecation warnings always feels wrong to me.

Any idea's on how you would like to prevent this change from breaking everybody's current setup?


Error reporting plugins register a class which implements a ``report`` method, which is invoked when a Django Q cluster encounters an error, pasing information to the particular service. Error reporters must be :ref:`configured<error_reporter>` via the ``Q_CLUSTER`` dictionary in your :file:`settings.py`. These settings are passed as kwargs upon initiation of the Error Reporter. Therefore, in order to implement a new plugin, a package must expose a class which will be instantiated with the necessary information via the ``Q_CLUSTER`` settings and implements a single ``report`` method.

For example implementations, see `django-q-rollbar <https://github.com/danielwelch/django-q-rollbar>` and `django-q-sentry <https://github.com/danielwelch/django-q-sentry>`
Copy link
Collaborator

Choose a reason for hiding this comment

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

I like that you provide examples except that they are references to a different repository.
Shouldn't django-q-rollbar be included by default in this repo?

Copy link
Contributor Author

@danielwelch danielwelch Oct 4, 2017

Choose a reason for hiding this comment

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

@Eagllus

Any idea's on how you would like to prevent this change from breaking everybody's current setup?

Understandable. To me, the most obvious and probably easiest solution is just to leave the old rollbar support in place along side the error reporter implementation. Then no one currently using rollbar support needs to modify their Q_CLUSTER settings, while new projects can instead use the error_reporter config setting and include the django-q-rollbar extra. Seems to me this would involve simply "putting back" what was removed from django_q/conf.py and django_q/cluster.py. I could modify the documentation changes to re-include the rollbar section, maybe with a note about that config setting being there for compatibility purposes and a link to the error_reporter setting. Maybe a deprecation warning if `Q_CLUSTER['rollbar'] is detected, if you're inclined.

I like that you provide examples except that they are references to a different repository.
Shouldn't django-q-rollbar be included by default in this repo?

In my opinion, different repositories is a strength (and kind of the point). I don't see any reason that django-q-rollbar should be included by default over, let's say, django-q-sentry aside from the backwards compatibility issue you brought up, which I think is valid. So the question seems to be, what is the best way to provide rollbar support for current users without breaking things: via Q_CLUSTER['rollbar']" vs. including django-q-rollbar in the django-q repository itself. To me, it seems cleaner to provide django-q-rollbar in the same way that django-q-sentry and potentially other plugins are provided: via a seperate repository. But I am but a hopeful contributor and those design decisions are probably not mine to make.

@danielwelch
Copy link
Contributor Author

@Eagllus I went ahead and implemented the suggestion I made above and modified documentation as well. This should prevent anything from breaking for those already using the rollbar setting.

Copy link
Collaborator

@Eagllus Eagllus left a comment

Choose a reason for hiding this comment

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

I like this a lot better!

@Koed00 can you do the final check?

@Koed00
Copy link
Owner

Koed00 commented Oct 9, 2017

Looks great @danielwelch . I agree that rollbar does not need to be included by default.
I initially added it cause that's what I use myself and I hoped some day someone would take it upon themselves to add support for other reporters. Happy someone took the initiative.

@Koed00 Koed00 merged commit 56c643f into Koed00:master Oct 10, 2017
@Koed00
Copy link
Owner

Koed00 commented Oct 10, 2017

I merged the code to master and fixed some of links in the sphinx documentation. Looks good.
Before I do a full release, I still want to merge some more stuff and run a some tests on my own servers.

@danielwelch danielwelch deleted the error-reporter branch October 11, 2017 11:23
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.

5 participants