kent

Fake Sentry server for local development, debugging, and integration testing

https://github.com/mozilla-services/kent

Science Score: 26.0%

This score indicates how likely this project is to be science-related based on various indicators:

  • CITATION.cff file
  • codemeta.json file
    Found codemeta.json file
  • .zenodo.json file
    Found .zenodo.json file
  • DOI references
  • Academic publication links
  • Committers with academic emails
  • Institutional organization owner
  • JOSS paper metadata
  • Scientific vocabulary similarity
    Low similarity (12.2%) to scientific vocabulary

Keywords from Contributors

interactive serializer packaging network-simulation shellcodes hacking autograding observability genomics embedded
Last synced: 11 months ago · JSON representation

Repository

Fake Sentry server for local development, debugging, and integration testing

Basic Info
  • Host: GitHub
  • Owner: mozilla-services
  • License: mpl-2.0
  • Language: Python
  • Default Branch: main
  • Size: 124 KB
Statistics
  • Stars: 120
  • Watchers: 5
  • Forks: 5
  • Open Issues: 3
  • Releases: 0
Created over 4 years ago · Last pushed about 1 year ago
Metadata Files
Readme Changelog License Code of conduct Codeowners

README.rst

====
Kent
====

Kent is a service for debugging and integration testing Sentry.

:Code:          https://github.com/mozilla-services/kent/
:Issues:        https://github.com/mozilla-services/kent/issues
:License:       MPL v2


Goals
=====

Goals of Kent:

1. make it possible to debug ``before_send`` and ``before_breadcrumb``
   sanitization code when using sentry-sdk
2. make it possible to debug other Sentry event submission payload issues
3. make it possible to write integration tests against a fake Sentry instance


Quick start
===========

Installing and running on your local machine
--------------------------------------------

1. Install Kent.

   (Recommended) With `uv `__::

      uv tool install kent

   Install from a git clone::

      uv tool install .

2. Run Kent::

      kent-server run [-h HOST] [-p PORT]
      

Running in a Docker container
-----------------------------

I'm using something like this::

    FROM python:3.11.5-slim-bookworm

    WORKDIR /app/

    ENV PYTHONUNBUFFERED=1 \
        PYTHONDONTWRITEBYTECODE=1

    RUN groupadd -r kent && useradd --no-log-init -r -g kent kent

    # NOTE(willkg): This installs Kent from main tip. If you're using Kent for
    # realzies, you probably don't want to do this because Kent could change and
    # break all your stuff. Pick a specific commit or tag.
    RUN pip install -U 'pip>=8' && \
        pip install --no-cache-dir 'kent=='

    USER kent

    ENTRYPOINT ["/usr/local/bin/kent-server"]
    CMD ["run"]


Make sure to replace ```` with the version of Kent you want to use.
See https://pypi.org/project/kent for releases.

Then::

    $ docker build -t kent:latest .
    $ docker run --init --rm --publish 8000:8000 kent:latest run --host 0.0.0.0 --port 8000


Things to know about Kent
=========================

Kent is the fakest of fake Sentry servers. You can set up a Sentry DSN to point
to Kent and have your application send events to it.

Kent is for testing sentry-sdk things. Kent is not for testing Relay.

Kent is a refined fake Sentry service and doesn't like fast food.

Kent will keep track of the last 100 payloads it received in memory. Nothing is
persisted to disk.

You can access the list of events and event data with your web browser by going
to Kent's index page.

You can also access it with the API. This is most useful for integration tests
that want to assert things about events.

``GET /api/eventlist/``
    List of all events in memory with a unique event id.

``GET /api/event/EVENT_ID``
    Retrieve the payload for a specific event by id.

``POST /api/flush/``
    Flushes the event manager of all events.

You can use multiple project ids. Kent will keep the events separate.

If you run ``kent-server run`` with the defaults, your DSN is::

    http://public@localhost:5000/1    for project id 1
    http://public@localhost:5000/2    for project id 2
    etc.


Kent definitely works with:

* Python sentry-sdk client
* Python raven client (deprecated)

I don't know about anything else. If you use Kent with another Sentry client,
add an issue with details or a pull request to update the README.


Development
===========

Requirements: Python, `uv `__, `just
`__

Create a development environment::

    just devenv

Then you can use rules listed in the ``justfile``::

    just

Owner

  • Name: Mozilla Services
  • Login: mozilla-services
  • Kind: organization

see also http://blog.mozilla.com/services

GitHub Events

Total
  • Issues event: 2
  • Watch event: 7
  • Delete event: 3
  • Member event: 1
  • Issue comment event: 4
  • Push event: 5
  • Pull request event: 11
  • Pull request review event: 6
  • Fork event: 1
  • Create event: 6
Last Year
  • Issues event: 2
  • Watch event: 7
  • Delete event: 3
  • Member event: 1
  • Issue comment event: 4
  • Push event: 5
  • Pull request event: 11
  • Pull request review event: 6
  • Fork event: 1
  • Create event: 6

Committers

Last synced: about 1 year ago

All Time
  • Total Commits: 90
  • Total Committers: 3
  • Avg Commits per committer: 30.0
  • Development Distribution Score (DDS): 0.2
Past Year
  • Commits: 20
  • Committers: 2
  • Avg Commits per committer: 10.0
  • Development Distribution Score (DDS): 0.5
Top Committers
Name Email Commits
Will Kahn-Greene w****g@m****m 72
dependabot[bot] 4****] 17
Mathieu Pillard d****x 1
Committer Domains (Top 20 + Academic)

Issues and Pull Requests

Last synced: 11 months ago

All Time
  • Total issues: 2
  • Total pull requests: 14
  • Average time to close issues: 4 days
  • Average time to close pull requests: about 15 hours
  • Total issue authors: 1
  • Total pull request authors: 2
  • Average comments per issue: 1.0
  • Average comments per pull request: 0.36
  • Merged pull requests: 13
  • Bot issues: 0
  • Bot pull requests: 6
Past Year
  • Issues: 1
  • Pull requests: 13
  • Average time to close issues: 8 days
  • Average time to close pull requests: about 17 hours
  • Issue authors: 1
  • Pull request authors: 2
  • Average comments per issue: 0.0
  • Average comments per pull request: 0.31
  • Merged pull requests: 12
  • Bot issues: 0
  • Bot pull requests: 6
Top Authors
Issue Authors
  • willkg (1)
Pull Request Authors
  • willkg (9)
  • dependabot[bot] (6)
Top Labels
Issue Labels
Pull Request Labels
dependencies (6) github_actions (4)

Dependencies

.github/workflows/main.yml actions
  • actions/checkout v3.1.0 composite
  • actions/setup-python v4.3.0 composite
Dockerfile docker
  • python 3.10.8-alpine3.16 build
requirements-dev.txt pypi
  • black ==22.10.0 development
  • build ==0.9.0 development
  • flake8 ==5.0.4 development
  • pytest ==7.2.0 development
  • requests ==2.28.1 development
  • sentry-sdk ==1.10.1 development
  • tox ==3.27.0 development
  • tox-gh-actions ==2.10.0 development
  • twine ==4.0.1 development