sneak
11c8b6b851
check / check (push) Waiting to run
Rewritten from scratch against the code on next; the sections and their contents are kept. Model: fable-5-1
69 lines
3.3 KiB
Markdown
69 lines
3.3 KiB
Markdown
# Workflow
|
|
|
|
One issue per unit of work, and one branch and one PR per issue:
|
|
|
|
- make sure a tracked issue exists with a definition of done
|
|
- branch from `next`, never from `main`
|
|
- do the work, then open a PR with base `next`, never `main`
|
|
- pass an independent review; the manager then squash-merges into `next`
|
|
- push; nothing stays local-only
|
|
|
|
`next` is the branch for the next milestone. It must stay green and mergeable
|
|
into `main` at all times. One PR from `next` into `main` accumulates the
|
|
milestone. Releases are cut from `main` separately.
|
|
|
|
The tracker (https://git.eeqj.de/sneak/webhooker/issues) records what is done
|
|
and what is under way. This file keeps no list of either.
|
|
|
|
# Status
|
|
|
|
What is still open for 1.0.0 is in its milestone
|
|
(https://git.eeqj.de/sneak/webhooker/milestone/9). `v1.0.0` is not tagged. Only
|
|
@sneak tags it.
|
|
|
|
Delivery is at least once by design. A send whose result row does not land is
|
|
sent again, so a receiver can see a duplicate. The alternative is a silent lost
|
|
delivery. The README says so under How it works. It is not a defect to re-file.
|
|
|
|
# Next Step
|
|
|
|
@sneak runs webhooker in limited production, then tags `v1.0.0`. Merging `next`
|
|
into `main` is a separate act from tagging and waits on neither. `next` is kept
|
|
mergeable at all times; that is the point of the branch.
|
|
|
|
# Future Steps
|
|
|
|
- Per-webhook rate limits, set in the web UI and enforced in the receiver. Today
|
|
`RECEIVER_RATE_LIMIT` sets one limit for every entrypoint on the server.
|
|
- API key authentication for programmatic access. The `APIKey` table exists, but
|
|
nothing creates a key and nothing checks one.
|
|
- REST API v1. `/api/v1` is mounted with no routes today.
|
|
- CRUD for webhooks, entrypoints and targets
|
|
- event viewing and filtering endpoints
|
|
- event redelivery endpoint
|
|
- OpenAPI specification
|
|
- Analytics in the web UI: response times summarised per webhook or per target,
|
|
and figures for all webhooks together. Today the webhook page shows event,
|
|
delivery and failure counts and failure percentages. The target list counts
|
|
each target's deliveries. The event log shows every attempt's duration.
|
|
`/metrics` carries server-wide counts and delivery durations.
|
|
- A remember-me option at login. Today every session survives a browser restart.
|
|
It lasts up to 7 days, and ends sooner after `SESSION_IDLE_TIMEOUT` (default
|
|
24 hours) without use.
|
|
- Password reset over the web for a forgotten password. Today a signed-in user
|
|
can change their password, and a lost password is reset from the console with
|
|
`webhooker resetpw` (https://git.eeqj.de/sneak/webhooker/issues/208).
|
|
- Later, nice to have
|
|
- email delivery target type
|
|
- SNS and S3 delivery targets
|
|
- data transformations, such as a configurable Slack message format; the
|
|
Slack target sends one fixed format today
|
|
- JSONL file delivery with periodic S3 upload. Today the `database` target
|
|
archives events to SQLite files, rotated hourly, daily or monthly if set,
|
|
and the webhook page offers them as one gzipped JSON download.
|
|
- webhook event search, and filtering beyond the event log's failed and
|
|
pending views
|
|
- multi-user with role-based access control. Today each webhook belongs to
|
|
one account, but only the account made at first boot exists and there is
|
|
no way to add another.
|