113 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
Niklas Ye	74359c72ab	Give each team its own dead man's switches, and the UI a team to show ... The rest of #4. Two halves that belong together because they are the same sentence from opposite ends: a team decides which of its alerts are heartbeats, and the UI has to be able to say which team it is talking about. Switches were three environment variables, which made them one setting for the whole install. That was the last piece of the alerting path a team could not control: it could take its own alerts on its own key and still not say which of them were heartbeats, or how long a silence had to last. They are a row per team now, edited by an owner through PUT /api/teams/{teamID}/deadman, and the sweeper runs each team against its own matchers, timeout and severity. The environment variables become the starting point rather than the setting. Every team without a configuration is seeded from them at startup, so an upgrade keeps watching exactly what it was watching, and SeedDeadmanConfigs never overwrites -- a redeploy must not put the environment's value back over an owner's edit. A team created later watches nothing until somebody says otherwise: inheriting an install-wide heartbeat would page a new team about a source it has never heard of, and a switch nobody chose is the kind that gets muted rather than fixed. A matcher string with no alertname in it is refused at the door instead of stored. Storing it would produce a switch that watches nothing silently, which is the exact failure the feature exists to prevent. NewRouter and Sweep lose their DeadmanConfig parameter -- there is no longer one answer to hand them. The type stays, because parsing a matcher string is still parsing a matcher string. The UI side: rows in the queue carry a team badge, the filter row gains a team chip per team, and "on call now" shows one card per team. All three appear only when the viewer is in more than one team -- otherwise they are the same word repeated down a list, which is noise rather than information, and the single-team install reads exactly as it did before teams existed. Verified against a live two-team server as well as in tests: the combined queue labelled by team, the team_id filter, a heartbeat that is a heartbeat in one team and an ordinary alert in another, and a new team's switches starting empty while the upgraded team keeps the environment's. Claude-Session: https://claude.ai/code/session_01RHPj4ggeFdEjKKfm4SHbD7	2026-09-20 15:18:22 +02:00
niklas	43f69272f0	Merge pull request 'Add a system administrator role, and gate account management behind it' (#10) from admin-role into main ... Reviewed-on: #10	2026-09-20 13:10:47 +00:00
niklas	2de5c8412d	Merge pull request 'Scope everything to a team, and route alerts by integration key' (#11) from teams into admin-role ... Reviewed-on: #11	2026-09-20 11:39:33 +00:00
Niklas Ye	a4fbd60441	Scope everything to a team, and route alerts by integration key ... The core of #4, and what #1 is for: terdut stops being one shared space. A team owns its incidents, alerts, schedule and integrations; a user sees exactly the teams they are in. Everything that existed moves into one Default team and every existing user becomes an owner of it, so the upgrade is a no-op for the people using it. Ingestion is the load-bearing half. An alert arrives on a team's integration key, and the key is both the credential and the routing: it says that the sender may post, and which team the alerts belong to. That also closes the unauthenticated webhook -- the old path stays for one release, deprecated and routed to the oldest team, so an upgrade does not stop delivering while somebody edits the Alertmanager config. Scoping is enforced in as few places as possible, because the failure mode is silent. serveAs loads the caller's memberships once; list queries carry `team_id = ANY(...)`; and every incident route goes through incidentIDParam, which now parses the id AND checks the team in the same call, so a new handler cannot remember the first half and forget the second. Anything in another team is 404, never 403: whether an incident exists is that team's business. Two bugs this found, both of which would have been silent: * upsertAlerts decided "is this a new occurrence" by looking up the fingerprint alone. Across teams that made team B's first alert look like a re-send of team A's, so it opened no incident at all. The lookups are keyed on (team_id, fingerprint) now, as the index is. * Every uniqueness rule was written for one tenant. Two teams watching two clusters legitimately see the same fingerprint, the same groupKey, and want somebody on call on the same day; all three constraints move to include team_id. Roles inside a team are separate from the system administrator flag: an owner configures the team, a member works its incidents, and an admin is NOT implicitly in every team -- administration is about accounts, not about reading other people's incidents. An admin can still repair a team whose owner has left, which is why requireTeamOwner lets them through. A shift can only be given to somebody in the team. Paging a person who cannot open the incident is worse than paging nobody. The UI is updated only as far as keeping it working: it loads the viewer's teams with the session and uses the first one, since nobody has a second yet. "On call now" shows every team the viewer is in, named only when there is more than one, so the common case reads exactly as before. The team switcher, badges and per-team settings pages are the next step. Breaking for API clients: the schedule endpoints moved under the team, and /api/schedule/current returns an array rather than an object or a 404. terdut-tui will need a version for that. Per-team dead-man configuration is deliberately not here. A heartbeat's incident already opens in the team whose key received it, which is the part that matters for isolation; moving the matchers out of env into per-team rows is a change to how deadman.go is configured rather than to who sees what. Claude-Session: https://claude.ai/code/session_01RHPj4ggeFdEjKKfm4SHbD7	2026-09-20 13:36:24 +02:00
Niklas Ye	1377d9005b	Add a system administrator role, and gate account management behind it ... Until now every authenticated caller could create and delete users, set anybody's password and mint anybody's API keys -- auth.go said so in a comment. Defensible with one operator and a hand-made account; not once people sign themselves up (#7), and not in a multi-tenant install (#4), where the user list is no longer everybody who works here. users.is_admin is the flag. AdminOnly gates creating and deleting users and granting the flag itself. The endpoints that are self-service for your own account and administration for somebody else's -- password, ntfy topic, API keys -- go through requireSelfOrAdmin instead, because which rule applies depends on the {id} in the path rather than on the route. Minting your own API key stays self-service. A key carries exactly the rights of the user it belongs to, so issuing one is no more than signing in again; requiring an admin for it would mean a responder cannot set up the TUI without somebody else in the room. /api/users stays readable by everybody. The queue's assignment control and the on-call schedule both have to name people, and hiding the roster from the people on it buys nothing. THE MIGRATION MAKES EVERY EXISTING USER AN ADMINISTRATOR. They already hold these powers, so nobody's access changes on upgrade: it names what is already true and leaves demotion as a deliberate act. Promoting only user 1 would silently strip the others, and could leave an install whose only administrator is an account nobody has a password for. Two guards keep an install administrable: the last administrator can be neither deleted nor demoted, and nobody can delete or demote themselves -- the likelier accident, where the only admin clears their own flag while tidying up and locks the door behind them. No UI changes: there are no account-management screens yet. models.User carries is_admin (not omitempty, so a client can tell false from an old server), which is what #5's admin page will render from.	2026-09-20 13:20:04 +02:00
Niklas Ye	e3ad19c110	Set the chart's placeholder version to 0.11.1 ... Cosmetic, as in 041e159 and 989425e. `make helm-package` passes --version and --app-version from the tag, so neither field decides anything about what release.yaml publishes. 0.11.0 never reached the registry -- its release run failed at the test gate -- so the placeholder moves on to the version that will. v0.11.1	2026-09-20 12:57:20 +02:00
Niklas Ye	a8ee742533	Give release.yaml's test job the database ci.yaml already has ... v0.11.0 was tagged and published nothing: release.yaml runs the same `make fmt lint test` as ci.yaml, and the Postgres service the suite now needs was added to ci.yaml alone. Its test job failed on the missing TERDUT_TEST_DSN, and binaries, image, chart and scan-image are all downstream of it, so they skipped. The tag stays -- a published tag is immutable and moving one is how this repo ran v0.4.0 for ten days while every artifact said v0.3.0 -- so the fix is the next version. The two workflows carry their own copies of this block because a service container cannot be factored into the Makefile the way the checks are. That is the second copy, and the reason this failed: the gate is one target, but what the gate needs to run is declared per workflow.	2026-09-20 11:12:41 +02:00
Niklas Ye	041e159e2a	Set the chart's placeholder version to 0.11.0 ... Cosmetic, as in 989425e and e78f494. `make helm-package` passes --version and --app-version from the tag, so neither field decides anything about what release.yaml publishes. Done anyway because a tree heading for v0.11.0 that still says 0.10.2 tells a reader something false. appVersion keeps the v, per APPVERSION_PREFIX in .release.conf. v0.11.0	2026-09-20 11:10:21 +02:00
niklas	cede8743a8	Merge pull request 'Take the database password from PGPASSWORD, not the DSN' (#9) from postgres-dsn-password into main ... Reviewed-on: #9	2026-09-20 09:07:32 +00:00
Niklas Ye	cc31c993dd	Take the database password from PGPASSWORD, not the DSN ... The chart asked for a whole DSN in a Secret. Nothing writes one: the Zalando postgres operator generates a Secret with `username` and `password` keys and no connection string, so wiring the wrapper chart up would have meant hand-maintaining a second copy of a password the operator owns and rotates on a from-scratch rebuild -- which is charts#176 again, the issue miniflux closed by doing the opposite. So the DSN becomes a plain value with no password in it, and the password arrives as PGPASSWORD from a Secret. pgx fills in from libpq's PG* environment variables whatever the DSN omits, exactly as miniflux's lib/pq does. Verified rather than assumed, against a real server: a password-less DSN connects with PGPASSWORD set, and fails with `password authentication failed` when it is wrong, so the variable is doing the work rather than being quietly ignored. It also keeps the credential out of the rendered manifest and out of `kubectl describe pod`, which a DSN-with-password does not.	2026-09-20 11:00:05 +02:00
niklas	21f0eec807	Merge pull request 'Move the database to Postgres' (#8) from postgres into main ... Reviewed-on: #8	2026-09-20 08:54:24 +00:00
Niklas Ye	dc39e3a5d3	Move the database to Postgres, before teams need the schema ... First step of #1, and it goes first for one reason: #4 adds a team_id to nearly every table, and doing that twice -- once for SQLite, once for Postgres -- is work nobody gets paid for. The teams migrations now only have to be written against one database. The ten SQLite migrations are replaced by a single Postgres baseline rather than ported one by one. They were incremental in a way that has no value on a fresh install: 004 adds columns 008 drops again, and 008's backfill rewrites data a Postgres database never had. The history stays in git; the schema they add up to is now 001_baseline.sql. Timestamps stay BIGINT unix seconds and are NOT converted to timestamptz. Everything in Go already speaks epochs, so converting would have been a second, larger change riding along inside this one. It is worth doing on its own. The JSON columns did move to jsonb, because #4 will want to filter and index on labels. Most of the port is mechanical -- 170 placeholders from ? to $1 -- but four things needed more than a search and replace: * Dynamically built WHERE clauses cannot keep their numbering straight by hand, so they hand out placeholders through sqlArgs instead. A filter can now be added or reordered without renumbering anything. * SUM(resolved_at IS NULL) was SQLite counting a boolean as 0 or 1. Postgres has no sum(boolean), and this was breaking every dead man's switch -- silently, since the sweeper only logs. Now COUNT(*) FILTER. * unixepoch() became FLOOR(EXTRACT(EPOCH FROM now()))::bigint. The FLOOR is load-bearing: a bare cast rounds half up, so a row written at .6 of a second claimed a timestamp a second in the future and disagreed with the time.Now().Unix() the Go side stamps. * The unique-violation check matched SQLite's error text. It matches SQLSTATE 23505 now, so a renamed constraint cannot turn a 409 back into a 500. Tests need a real Postgres, because there is no in-memory Postgres the way there was an in-memory SQLite. Each test gets its own schema on a shared server -- cheaper than a database each, and still isolated. TERDUT_TEST_DSN says where it is; `make test-db` starts one locally and ci.yaml runs one as a service container. An unset DSN fails the suite rather than skipping it: a run that quietly tests nothing is worse than one that does not run. TestMigration_BackfillCarriesAckAndComments is deleted along with the migrations it replayed. What it protected -- an upgrade not losing acknowledgements and comments -- now belongs to scripts/sqlite-to-postgres.go, which is build-tagged so the SQLite driver stays out of the server binary. Both are meant to be deleted once this install has migrated. The chart loses the PVC, the data volume and the python backup sidecar, and requires database.dsnSecret.name: it provisions no database and cannot guess where the credentials live, so a render without it is meant to fail. Backups move to where Postgres actually runs. The other half of that -- the postgresql CR, the k8up pg_dump annotation and the network policy -- is a change to the wrapper chart in Ryuvia/charts and is not in here. Verified rather than assumed: the gate is green with -race against Postgres 17, govulncheck and gitleaks are clean, and the migration script was run end to end against a SQLite database built at the old schema and seeded in every table. Ids survive, so incidents keep their numbers and every foreign key still points where it did; the identity sequences are moved past the copied ids, and a webhook after the migration opened incident 12 rather than colliding at 1.	2026-09-20 10:44:12 +02:00
Niklas Ye	989425e550	Set the chart's placeholder version to 0.10.2 ... Cosmetic, as in e78f494 and 4cec26e. `make helm-package` passes --version and --app-version from the tag, so neither field decides anything about what release.yaml publishes. Done anyway because a tree heading for v0.10.2 that still says 0.10.1 tells a reader something false. appVersion keeps the v, per APPVERSION_PREFIX in .release.conf. v0.10.2	2026-09-19 18:05:06 +02:00
Niklas Ye	5b1ab2c568	Move x/crypto to v0.55.0, clear of the ssh CVEs ... v0.10.1's image published, but scan-image refused it. trivy reports ten HIGH advisories against golang.org/x/crypto v0.49.0, CVE-2026-39828 through CVE-2026-56854, all of them in x/crypto/ssh and its agent and knownhosts packages. The last is fixed in 0.55.0 and the rest in 0.52.0. None of them is reachable here. The server imports x/crypto/bcrypt and nothing else from the module, and the image is FROM scratch, holding a single binary. But trivy scans at module granularity and cannot tell that. Shipping a known-vulnerable module version on the strength of a reachability argument is not the call to make inside a dependency pin, so the version moves instead. 9abf07f was wrong to call v0.49.0 the newest release that keeps go.mod at go 1.25.9. v0.55.0 keeps it there too; the directive is unchanged here. What had held it at 1.26 was the x/sys v0.48.0 that v0.57.0 pulled in. The `go get golang.org/x/sys@v0.42.0` meant to undo that then downgraded x/crypto to v0.49.0 to match, without being asked. x/sys now sits at v0.47.0, the version x/crypto v0.55.0 requires. Checked before tagging rather than by the pipeline: the gate passes, the Dockerfile builds on its Go 1.25 builder, and trivy, run locally with the same flags as `make security-image` (HIGH and CRITICAL, fixed only), exits 0 on the image that build produced.	2026-09-19 18:05:06 +02:00
Niklas Ye	e78f49461a	Set the chart's placeholder version to 0.10.1 ... Cosmetic, as in 4cec26e and 9669b8f. `make helm-package` passes --version and --app-version from the tag, so neither field decides anything about what release.yaml publishes. Done anyway because a tree heading for v0.10.1 that still says 0.10.0 tells a reader something false. appVersion keeps the v, per APPVERSION_PREFIX in .release.conf. v0.10.1	2026-09-19 17:56:20 +02:00
Niklas Ye	9abf07f2cb	Build on Go 1.25 again, as the Dockerfile does ... v0.10.0 never produced an image. Adding bcrypt in dc3879e ran `go get golang.org/x/crypto`, which took the newest release, v0.57.0. That version declares `go 1.26.0`, and so does the x/sys v0.48.0 it pulled along, so go.mod's own directive rose from 1.25.9 to 1.26.0. The Dockerfile builds on golang:1.25-alpine with GOTOOLCHAIN=local, and refused: go: go.mod requires go >= 1.26.0 (running go 1.25.14; GOTOOLCHAIN=local) Nothing before the image job could see it. The local toolchain is 1.26, and the pipeline's test job runs on the runner's Go rather than in the Dockerfile's builder. So the gate passed on a module the image could not build. Pinned to x/crypto v0.49.0 rather than moving the builder to 1.26. That is the newest release whose own requirements leave go.mod at 1.25.9 and x/sys where it was. Changing the toolchain the image is built with belongs in its own change, not inside a dependency addition. go.mod now differs from v0.9.4 by the one crypto line and nothing else. bcrypt has not changed in any way that matters here across those releases. Checked by building the Dockerfile locally, which now succeeds. The resulting container serves /incidents/3 as the web UI and answers /api/me with a JSON 401.	2026-09-19 17:56:20 +02:00
Niklas Ye	4cec26edde	Set the chart's placeholder version to 0.10.0 ... Cosmetic, as in 9669b8f and f46e5f5. `make helm-package` passes --version and --app-version from the tag, so neither field decides anything about what release.yaml publishes. Done anyway because a tree heading for v0.10.0 that still says 0.9.4 tells a reader something false, and the tree is what gets read before the tag exists. appVersion keeps the v, per APPVERSION_PREFIX in .release.conf. v0.10.0	2026-09-19 17:48:28 +02:00
Niklas Ye	dc3879eca6	Serve a web UI for the incident queue, built for phones ... Whoever is on call gets paged on a phone, and until now the only ways to act on a page were the notification's Acknowledge button or a terminal. Tapping the notification itself opened /api/incidents/{id}, which a browser can only answer with a 401 in JSON. The server now serves a web UI at / covering the incident queue, each incident's alerts and timeline with every action on it, who is on call, the alert feed, and changing your own password. The notification link now points at /incidents/{id} in that UI. It is embedded in the binary and has no build step: plain HTML, CSS and ES modules under internal/web/static, served with an ETag per file and a CSP that allows nothing from any other origin. That is how rd-web is built. It avoids adding a node toolchain to the Dockerfile and the pipeline for a page this size, and it keeps the page on the same origin as the API, so no CORS is needed and nothing else has to be deployed. Paths without a file extension fall back to index.html, so a deep link survives a reload. An unknown path under /api/ still gets a JSON 404 rather than the page. Signing in uses a username and password, because pasting a 64-character API key into a phone at 3am is not a sign-in flow. Users have no password until one is set through PUT /api/users/{id}/password, or optionally at bootstrap. A user without a password is exactly where they were before this commit and can only use API keys. A login sets an HttpOnly, SameSite=Lax session cookie. It lasts 30 days and slides forward while in use, so an on-call phone does not sign itself out. Only the token's hash is stored, as for API keys. The cookie needs a CSRF guard where a bearer header does not, because browsers attach cookies to requests other sites make. So cookie- authenticated requests go through Go 1.25's http.CrossOriginProtection, and bearer requests do not. A request carrying an Authorization header is judged on that header alone and never falls back to the cookie. Changing a password ends every other session of that user. Changing your own requires the current password, so a phone left signed in cannot be used to take the account over. Failed logins are counted per username and per client address. Ten failures for one username in 15 minutes refuse that username for the rest of the window, even with the right password. That makes locking somebody out possible for anyone who knows their username. It was accepted because the alternative is unlimited guessing, and during a lockout the notification's Acknowledge button and API keys keep working. The address limit reads the first X-Forwarded-For hop, since behind the gateway RemoteAddr is Envoy. It is looser, because a whole office behind one NAT shares it. The Secure flag follows TERDUT_PUBLIC_URL, since TLS terminates at the gateway and the server itself only ever sees plain HTTP. The chart already defaults that variable to https://<hostname>. Schedule editing, statistics and user management stay in terdut-tui for now. The API they use is unchanged, and bearer authentication behaves exactly as before.	2026-09-19 17:48:21 +02:00
Niklas Ye	9669b8f477	Set the chart's placeholder version to 0.9.4 ... Cosmetic, as in f46e5f5. `make helm-package` passes --version and --app-version from the tag, so neither field decides anything about what release.yaml publishes. Done anyway because a tree heading for v0.9.4 that still says 0.9.3 tells a reader something false, and the tree is what gets read before the tag exists. appVersion keeps the v, per APPVERSION_PREFIX in .release.conf. Claude-Session: https://claude.ai/code/session_014m2pJdpCTv3mvvUUuBM54Y v0.9.4	2026-09-04 18:08:21 +02:00
Niklas Ye	a7871ed7c6	Stop the bootstrap hook installing curl at run time ... The hook's container was alpine:3 and its first line was `apk add --no-cache curl`. That writes the binary into the container's writable upper layer, and every exec of it afterwards is, correctly, a dropped binary: Falco's `Drop and execute new binary in container` (PCI_DSS_11.5.1, MITRE TA0003) fired twice at Critical on the upgrade to chart 0.9.3, 65ms after the container started, with evt.arg.flags=EXE_WRITABLE|EXE_UPPER_LAYER. Ryuvia/charts#100 has the event lines. A true positive of the rule and a false positive of intent, and it is not a one-off: the hook is post-install,post-upgrade, so it recurred on every release. The cluster is still in the Falco burn-in with detections routed to a null receiver, which is the only reason nobody was paged for it. Fixed here rather than with a Falco exception on purpose. An exception would have to name this container and would then stay in the rule set forever, blinding it for the one workload that already runs as root with create-secret RBAC, and it would leave the second problem untouched: this runs as a post-upgrade hook, a failed hook fails the release, so every `helm upgrade` of terdut-server depended on dl-cdn.alpinelinux.org answering. That dependency is now gone. alpine/curl is still a full Alpine, so sh, cat, sleep, grep, cut, head and tail are all present -- verified in-cluster before the swap rather than assumed, since a missing utility would surface as a failed post-upgrade hook and not as anything visible here. Digest-pinned, as the wrapper chart's own sidecar images are. The image declares an ENTRYPOINT, which the Job's `command:` overrides; a comment says so, because rewriting that to `args:` would silently run curl's entrypoint instead of the script. No change to the script's logic, to the RBAC, or to when the hook runs. Nothing on the terdut-tui side of the API moves, and no terdut-tui version is required or excluded by this. Worth recording while it is in view, and deliberately not acted on here: there is no terdut-server-admin-key secret in the namespace, so the POST returns 403, the hook logs "Server already bootstrapped, nothing to do" and exits before the secret-creating branch. On an upgrade this hook currently achieves nothing at all. Narrowing it to post-install would remove the detection outright, but that changes what the hook is for and belongs in its own change. Claude-Session: https://claude.ai/code/session_014m2pJdpCTv3mvvUUuBM54Y	2026-09-04 18:08:05 +02:00
Niklas Ye	79f5db2636	Scan the source and the working tree too, not just the image ... The image scan added yesterday reads the built artifact. It cannot see a vulnerable dependency the binary never calls into, and it cannot see a credential in a file that never reaches the image — this one is FROM scratch and contains a single binary, so almost nothing in the repo is in it. Those are two different questions and they need two different tools, which is why riksdata and rd-web have run govulncheck and gitleaks all along. Both run on every push and pull request rather than only on a tag, since neither needs anything published. Checked by hand before wiring in, as with the image scan. govulncheck reports no vulnerabilities the code can reach, and gitleaks finds nothing in the tree. What govulncheck does report is worth writing down, because it is the argument for having it. It found three advisories in chi and reports none of them, all three being IP spoofing in middleware.RealIP, which router.go does not use — it uses Logger and Recoverer. The analysis is symbol-level rather than dependency-level, so adding middleware.RealIP would turn this red on the next push. That is precisely when someone should be made to look, and it is a plausible thing to reach for here, since the API sits behind a gateway and real client addresses are exactly what RealIP is for. The fourth finding is an integer overflow in golang.org/x/sys/windows, which a linux/scratch image will not be calling. Both gates were checked for the failure direction as well. gitleaks exits 1 on a private key block. Worth knowing when testing it: it allowlists well-known example credentials, so the AWS key from Amazon's own documentation does not trip it and proves nothing. Neither reads git history. gitleaks runs with --no-git, which scans the working tree, so it stops a secret on the way in and says nothing about what is already committed. Claude-Session: https://claude.ai/code/session_01S7R4gWTz5wh5xCY4nCSJjN	2026-09-02 10:11:13 +02:00
Niklas Ye	84146fc903	Scan the published image for known vulnerabilities ... terdut-server was the only one of the three release-managed repos with no image scanning at all. riksdata and rd-web have had a scan-image job since they were set up; everything published here up to and including v0.9.3 went out without a CVE check. It scans the pushed image rather than a locally built one, for the same reason the siblings do: trivy cannot read a local image on this runner, since Talos has no docker socket and the dind sidecar shares no filesystem with the job. So it runs after image rather than gating it, and a red scan unpublishes nothing. What it means is narrower and worth stating plainly: do not bump the wrapper chart in Ryuvia/charts to that version. Checked before wiring it in rather than after. v0.9.3 scans clean at HIGH,CRITICAL with unfixed findings ignored, so this does not turn the pipeline red on arrival, and the same command exits 1 on an image that does have findings — a gate that cannot fail is not a gate. One platform is scanned, not both. The image is FROM scratch, so there are no OS packages and trivy sees a single target: the Go binary and its module graph. linux/amd64 and linux/arm64 are that same module set built for a different GOARCH, so a finding in one is a finding in both. On an image with a base layer that reasoning would not hold. Still no govulncheck and no gitleaks here, which riksdata and rd-web run in a separate CI job. This is the only security scanning terdut-server has. Claude-Session: https://claude.ai/code/session_01S7R4gWTz5wh5xCY4nCSJjN	2026-09-02 10:04:51 +02:00
Niklas Ye	c6f1fe317e	Correct the docs that said this repo has no publishing targets ... Both CLAUDE.md and README.md claimed there were deliberately no build or push targets because the workflow owned publishing. That stopped being true in 69fcc24, which moved publishing onto the Makefile so release.yaml could call it — the docs described the arrangement that change replaced. The claim was wrong in its reasoning too, not just out of date. It was written on the assumption that riksdata and rd-web duplicated their pipelines by having those targets. They never did: their workflows call make and always have, which is what makes a green gate locally and a green pipeline the same code instead of two descriptions of it. This repo was the exception, for the single day it had a Makefile that nothing called. Claude-Session: https://claude.ai/code/session_01S7R4gWTz5wh5xCY4nCSJjN	2026-09-01 22:44:22 +02:00
Niklas Ye	f46e5f5729	Set the chart's placeholder version to 0.9.3 ... Cosmetic, and done anyway, for the same reason as 477454e: these two lines decide nothing about what is published — `helm package --version --app-version` now sets both from the tag, so they are not even read during a release — but a tree heading for v0.9.3 that says 0.9.2 tells its reader something false. The comment above them was rewritten to stop naming a specific version. It described the tree as "heading for v0.9.2", which is exactly the kind of line that has to be edited every release and is therefore the kind that goes stale. It also said nothing that publishes looks at these fields, which only became literally true in 69fcc24 when the sed was replaced by helm's own flags. Claude-Session: https://claude.ai/code/session_01S7R4gWTz5wh5xCY4nCSJjN v0.9.3	2026-09-01 22:38:41 +02:00
Niklas Ye	69fcc24a4d	Drive the pipeline through make, the way riksdata and rd-web do ... Both workflows restated the build in YAML: gofmt, go vet and go test inline in two places, buildx inline in a third, and the chart's version sed'd into Chart.yaml before packaging. The Makefile added in 1081260 then described the same checks a second time for local use, which made "green locally means green in CI" a promise about keeping two files in step rather than a property of the setup. riksdata and rd-web never had that problem — their workflows call make and have done all along. This repo was the odd one out, and only because it had no Makefile until today. Now ci.yaml runs `make fmt lint test`, release.yaml runs the same plus `make binaries`, `make push`, `make helm-package` and `make helm-push`, and the reasoning behind each check lives on the target rather than in whichever YAML file was edited last. Three things change rather than just move: The chart is linted before it is published. release.yaml packaged and pushed without ever rendering the templates, so a chart that did not compile would have reached the registry and been found by Flux. ci.yaml gained a chart job for the same reason. helm package --version --app-version replaces the sed. The published metadata is identical, but the tree is no longer mutated mid-build, and it is what the rest of the release process already assumed happened. `make push` refuses VERSION=dev. Publishing is one command now, so it is also one command to run by accident; dev is not a version anyone releases. Deliberately not moved: uploading the release assets. Compiling them is `make binaries` and runs anywhere, but the upload needs a token and the Gitea release API, which is the workflow's business and not something worth a target. `push` builds and pushes in one step, unlike riksdata's separate build and push, because buildx cannot load a multi-platform image into the local store — it can only push it. `build` stays single-platform and local-only. Claude-Session: https://claude.ai/code/session_01S7R4gWTz5wh5xCY4nCSJjN	2026-09-01 22:36:54 +02:00
Niklas Ye	6a4f902e38	Declare that this repo's release prose is English ... The release skill's house style opened with "everything here is written in Swedish", stated as a house default. It is not one: Swedish belongs to riksdata and rd-web because their interface copy and the riksdag data they present are inseparable from it. Nothing about an on-call tool is — the labels, the API and the data here are English, and so are the code comments and the docs. Stated as a rule that was remembered rather than read, it produced the whole of v0.9.2 in Swedish: four commits, the tag body and both charts PRs. The PRs were rewritten; the commits on main and the published tag could not be, so v0.9.2 stays as the record of the mistake. PROSE_LANG makes it a declaration each repo carries, which release-preflight prints on the prose line before any of the four texts get written. See reference/house-style.md in the skill. Claude-Session: https://claude.ai/code/session_01S7R4gWTz5wh5xCY4nCSJjN	2026-09-01 22:24:41 +02:00
Niklas Ye	5f9c202d65	Beskriv hur ett släpp går till, och vad som är särskilt här ... Repot kom in under den gemensamma släppprocessen i 1081260 utan att någon dokumentation sa det. README hade Kubernetes och Development men ingenting om vägen från en commit till något som rullar i klustret, och till skillnad från riksdata och rd-web fanns ingen CLAUDE.md alls. Två saker om just det här repot är värda att stå skrivna, eftersom båda avviker från syskonrepona och båda upptäcktes mitt i ett släpp: Pipelinen har ingen bildskanning. riksdata och rd-web kör trivy efter publiceringen; .gitea/workflows/release.yaml här har test, binaries, image och chart och inget mer. Ett grönt släpp är alltså inget belägg för att bilden är fri från kända sårbarheter, och en släppnot får inte antyda det. Wrapperchartets values.yaml har två tag:-rader, appbilden och python-sidovagnen för säkerhetskopiering, så chart-bump behöver --image för att veta vilken som flyttas. Utan den vägrar den, vilket är rätt. Samtidigt: varför det inte finns några build- eller push-mål, varför chartet publiceras enbart från taggen (766f439), och varför make test kör -race när CI inte gör det. Helm-exemplet pekade fortfarande på 0.9.0 och går till 0.9.2. Claude-Session: https://claude.ai/code/session_01S7R4gWTz5wh5xCY4nCSJjN	2026-09-01 22:09:15 +02:00
Niklas Ye	477454ec3c	Sätt chartets platshållarversion till 0.9.2 ... Kosmetiskt, och görs ändå. .gitea/workflows/release.yaml stämplar både version och appVersion från git-taggen när det publicerar (766f439), så de här två raderna avgör ingenting om vad som hamnar i registret. Det enda de gör är att bli lästa, och de sa 0.9.0 och "latest" genom både v0.9.0 och v0.9.1 — ett träd på väg mot v0.9.2 som säger 0.9.0 påstår något falskt om sig självt. Första gången det görs i det här repot, så det finns inga tidigare tillfällen att hänvisa till. Kommentaren ovanför raderna skrevs om samtidigt: den hävdade att "latest" var ärligt eftersom det matchade image.tag i values.yaml, vilket slutade gälla i och med den här ändringen. image.tag ligger kvar på "latest", som är vad en lokal installation faktiskt drar; appVersion är metadata och styr ingenting. Att låta kommentaren stå kvar hade varit sämre än ingen kommentar alls, eftersom den är det en läsare kontrollerar fälten mot. Claude-Session: https://claude.ai/code/session_01S7R4gWTz5wh5xCY4nCSJjN v0.9.2	2026-09-01 21:48:48 +02:00
Niklas Ye	10812606bf	Lägg terdut-server under den gemensamma släppprocessen ... Släppprocessen (~/.claude/skills/release) körde hittills bara riksdata och rd-web, och vägrade den här katalogen med "not one of the release-managed repos". Den kräver två saker: en .release.conf och ett release-vars-mål som skriver ut IMAGE, HELM_CHART och HELM_REPO. Poängen med att fråga make i stället för att upprepa värdena i processen är att de bara kan ha en definition, så det som taggas, det som pushas och det som wrappern pinnar inte kan glida isär. Makefilen är avsiktligt inte en kopia av riksdatas. Två skillnader: fmt, lint och test speglar .gitea/workflows/ci.yaml steg för steg, så ett grönt "make fmt lint test" här betyder samma sak som en grön CI. gofmt-målet är kopierat ordagrant och inte förenklat, eftersom gofmts två felsätt inte är lika: en felformaterad fil listas på stdout med exit 0, medan en fil som inte går att parsa ger tom stdout och exit 2 — och den naiva varianten läser det andra som framgång (9046f6e). Undantaget är -race, som CI inte kör: sveparen, notifieraren och deadman-svepet delar en enda databasanslutning, och en kapplöpning där dyker upp som en flaxig incident i produktion i stället för som ett rött bygge. Det finns medvetet inga build-, push- eller helm-push-mål, till skillnad från riksdata och rd-web. Här äger .gitea/workflows/release.yaml publiceringen, och den gör två saker en lokal make inte gör: bygger linux/amd64 och linux/arm64 genom buildx, och stämplar chartets version och appVersion från taggen. Ett vanligt "docker build && docker push" skulle lägga en enarkitektursbild över den multiarkitekturella taggen — lätt att göra av misstag och osynligt efteråt, eftersom taggen fortfarande svarar, bara inte på arm64. Publicering sker genom att pusha en tagg, inget annat. Claude-Session: https://claude.ai/code/session_01S7R4gWTz5wh5xCY4nCSJjN	2026-09-01 21:47:59 +02:00
Niklas Ye	94dec19976	Räkna en tom incidentlista som noll i stället för som ett fel ... SUM över noll rader är NULL i SQLite, inte 0. handleStatsIncidents läste de tre statusräknarna rakt in i int64, så i samma stund som filtret inte matchade någon rad föll skanningen på "converting NULL to int64 is unsupported" och hela /api/stats/incidents svarade 500. COUNT(*) ger däremot 0 utan knot, vilket är precis varför felet inte syns förrän tabellen töms — det är det enda uttrycket i satsen som klarar noll rader. Filtret är alltid på: statsFilter lägger på archived_at IS NULL (923fc8b, flyttat hit i 279ef6c). En installation som varit tyst ett tag arkiverar därmed sig själv in i felet. Det är sluttillståndet för en lugn vecka, inte ett kantfall, och klustret står i det nu. Symptomet pekade åt fel håll. terdut-tui hämtar listan och statistiken i samma uppdatering, så incidentvyn såg trasig ut medan /api/incidents svarade 200 med []. Loggen i klustret visar de två anropen bredvid varandra, det ena grönt och det andra rött. Ingen ändring i terdut-tui behövs: dess ListIncidents är oförändrad sedan 0.7.2 och skickar samma parametrar som förut. handleStatsAlerts bar samma fel och rättas likadant, innan någon hittar det på samma sätt. COALESCE i SQL i stället för sql.NullInt64 i Go, eftersom jämförelserna redan bor i satserna här (severityRankSQL, 279ef6c). mtta_seconds och mttr_seconds lämnas medvetet utan COALESCE. null betyder "inget att mäta ännu" och 0 skulle läsas som "omedelbart" — två olika påståenden, och testet från 279ef6c låser fast skillnaden. Claude-Session: https://claude.ai/code/session_01S7R4gWTz5wh5xCY4nCSJjN	2026-09-01 21:47:39 +02:00
Niklas Ye	9046f6e026	ci: fail on code that is not gofmt'd ... go vet says nothing about import order, so when the move to git.ryuvia.com rewrote every import path without re-sorting them -- the new path sorts before github.com/..., where the old one sorted after -- both repos went through a green CI run and a release unformatted. Added to the release workflow as well as CI, so the two keep running the same checks; ci.yaml's header claims exactly that, and a check in one but not the other would quietly make it false. The step handles gofmt's two failure modes separately because they do not look alike: a misformatted file is listed on stdout with exit 0, so the failure has to be raised by hand, while a file that does not parse prints nothing to stdout and exits 2 -- which a plain emptiness test reads as success. Verified against all three cases (clean, misformatted, unparseable) before committing.	2026-08-19 21:29:35 +02:00
Niklas Ye	03504b61be	gofmt: restore import grouping after the module rename ... The rename to git.ryuvia.com/niklas/... was a plain string substitution, so it left the import blocks in their old order. The new path sorts before github.com/go-chi/..., where the old one sorted after, which gofmt considers unformatted. go vet does not look at import order, so CI had nothing to say about it.	2026-08-19 21:21:33 +02:00
Niklas Ye	6047d1a9f7	ci: do not override HELM_REPOSITORY_CACHE alongside the config ... Helm writes a refreshed repository index to the default cache directory and then looks for it in the overridden one, so setting both is how the chart tooling breaks on this machine already. v0.9.1	2026-08-19 20:44:06 +02:00
Niklas Ye	289eca8076	Move to Gitea: git.ryuvia.com/niklas/terdut-server ... The module path, the container image, the Helm chart and the CI pipeline all named GitHub. They now name the Gitea instance everything else already runs on. The workflows are rewritten rather than translated. Gitea's runner image is ubuntu:22.04, whose nodejs is Node 12, so no JS action runs there at all -- actions/checkout@v4 dies with a SyntaxError before it does anything. Every step is shell, checkout is a plain clone (this repo is public, so it needs no credential), and the jobs that need docker or helm run in host mode because the dind bridge a `container:` job gets cannot reach github.com or get.helm.sh. Two consequences worth naming: - upload-artifact/download-artifact are also JS actions, and there is no artifact store here, so the job that builds the binaries is the job that publishes them. Nothing is passed between jobs. - setup-qemu-action is gone with the rest, and the runner has no binfmt registration. The Dockerfile's builder stage now runs on $BUILDPLATFORM and cross-compiles from TARGETARCH instead, which is what keeps the arm64 image buildable -- and makes it native rather than emulated. The chart moves from a GitHub Pages index to an OCI artifact in Gitea's registry. Publishing stays tag-only for the reason recorded in release.yaml: a workflow triggered by the branch push cannot know the version it is about to be tagged with. The GitHub repository is left in place and untouched. Nothing pushes to it any more, but its existing release downloads and chart index keep resolving.	2026-08-19 20:39:10 +02:00
Niklas Ye	766f43931c	chart: publish from the tag only, not from both workflows ... Two workflows published the chart and disagreed about its metadata. release.yml stamps version and appVersion from the git tag; chart-release.yml, triggered by any charts/** push to main, took Chart.yaml verbatim, where appVersion is the hardcoded "latest". Both fired for the same commit, both tried to publish the same chart version, and skip_existing turned whichever lost into a no-op — so what a release said about itself came down to which runner was quicker. Chart 0.9.0 went out that way, reading appVersion "latest". Every earlier release got the right answer by accident: Chart.yaml's version lagged the published set, so chart-release.yml always collided with an existing version and skipped, leaving release.yml to win uncontested. Bumping Chart.yaml to match the tag before cutting 0.9.0 removed that accident and the race showed itself. Making the two agree is not possible. The tag is pushed after the branch, so a workflow triggered by the main push cannot know the version it is about to be tagged with — no amount of deriving from git describe fixes that ordering. The fix is one publisher, triggered by the tag, so chart-release.yml is deleted. The chart now only ships with an app release. Nothing is lost: the sed in release.yml ties the chart version to the app version, so a chart-only change never had a version of its own to be released under. Chart fixes ride the next tag. Chart.yaml's version and appVersion are documented as the placeholders they now are, so the next person does not helpfully bump them and reintroduce this. skip_existing stays, for idempotent re-runs of a failed release rather than for the race, and a non-version tag now fails the job instead of silently publishing unstamped metadata.	2026-08-08 21:41:44 +02:00
Niklas Ye	14c24f8fda	Notice when the Watchdog alert stops arriving ... Everything this server does assumes alerts arrive. If Prometheus stops evaluating, or Alertmanager cannot reach us, nothing arrives — and silence is indistinguishable from everything being fine. The cluster has shipped the alert for exactly this case all along: Watchdog is expr: vector(1), so it fires permanently and is re-sent forever, and it is worth nothing unless something downstream notices it stop. Nothing did. It arrived, opened no incident because a repeat_interval re-send is not a new occurrence, and when the monitoring stack died the sweeper quietly expired it and paged nobody. So the handling is inverted for a configurable set of alerts: receiving one opens no incident, and the absence of one does. TERDUT_DEADMAN_MATCHERS selects them as label matchers, defaulting to alertname=Watchdog. The unit of monitoring is the fingerprint rather than the alert name. Two clusters sending the same Watchdog are two independent switches, so a healthy one can never mask a dead one. Every matcher must name an alertname, which keeps the sweeper's candidate query on alerts_name_idx instead of JSON-extracting labels from every row, and leaves matching with a single implementation. A switch is dormant until its first heartbeat: a matcher nothing has ever sent opens nothing, so a fresh deploy or a restored database does not page. Resolving the incident by hand sticks, exactly as it does for an alert-backed one, so a decommissioned source is a one-time page rather than a nag; the switch re-arms only when the heartbeat comes back, and dying again is a new incident. The incident has no member alerts on purpose. Linking the heartbeat would have the settled-incident cascade close it on the very sweep that opened it, and there is no alert describing the problem anyway — the problem is that no alert arrived. What happened is on the timeline instead, and recovery is the only automatic way out. One narrow exemption in the ingest guard makes recovery possible at all. A heartbeat we declared dead is marked resolved, and the one that proves us wrong carries the unchanged startsAt of an alert that never stopped firing — so "resolution is terminal within an instance" would discard it forever and a switch could die exactly once. The exemption is scoped to resolution_source = 'deadman', which is the only resolution this server infers from silence on a timeout of its own, so nothing another writer set can be undone by a stale retry. Matched alerts are also held back from the generic staleness expiry, which would otherwise resolve a heartbeat as 'expiry' long before its own tighter deadline. The timeout points the opposite way to TERDUT_STALE_AFTER: staleness is a generous grace period around a repeat_interval you do not control, while this is a deadline you set deliberately and configure the heartbeat's route to beat. Inheriting a 4h or 12h repeat_interval gives a dead man's switch with a twelve hour fuse, so the README spells out the route the heartbeat needs. v0.9.0	2026-08-08 21:28:55 +02:00
Niklas Ye	e5916d522a	Let an on-call day be handed to somebody else ... A date is held by exactly one person and POST /api/schedule plain-inserts, so any date that was already taken came back 409. That made reassignment impossible through the API: the only route was to delete the entry first, and for a week that meant seven separate deletions. Worse, the reject is all-or-nothing across the request, so assigning a week where a single day happened to be taken failed entirely and placed none of the other six. The refusal itself is worth keeping. Moving a shift off the person expecting to be paged for it should not be something a plain call does by accident, so the fix is to make it possible to ask for rather than to remove the guard: "replace": true takes the dates anyway, and the flag defaults to off so every existing caller behaves exactly as before. The delete and the insert share the transaction that was already there. That matters more than the flag does — a week of free and taken days now lands as a unit, and a failure part way through leaves the rota as it was instead of with a shift deleted and nothing put back. A rota with a hole in it is worse than a rota that refused to change. One consequence worth naming: under replace a date repeated inside one request is idempotent rather than a conflict, because the second pass clears what the first wrote. v0.8.0	2026-08-07 14:04:11 +02:00
Niklas Ye	4224dbe96c	Record notification delivery on the incident timeline ... An incident's history went quiet after "Incident opened": nothing said that anybody had been paged, reminded, or told it resolved. Delivery lived only in the notifications outbox, which no API exposes, so when a page failed to arrive there was nothing in the product that said whether it had been sent. The notifier now writes two event types. A notified event once ntfy accepts the publish, carrying the kind in detail and the paged user in user_id — absent when the page went to the shared fallback topic, which belongs to nobody. And a notify_failed event when a notification exhausts its retries, which is the one worth having: without it a page that never landed leaves the timeline identical to one that did. Both are written from the delivery result rather than at enqueue. A queued notification is an intention, and the timeline is append-only, so claiming somebody was told before ntfy accepted it would be a lie that stays there. A failed timeline write is logged rather than returned, so it cannot make a delivered row look unsent and send the page twice. The topic is deliberately in neither: it is a shared secret with the ntfy server, and every API key can read the timeline. No migration — incident_events.type is free text, unlike notifications.kind. v0.7.0	2026-08-07 13:31:03 +02:00
Niklas Ye	17ee290d90	docs: the ack token is scoped, not single-use ... The handler never deletes the token: it stays valid until expires_at and is purged by the sweeper, so a second tap is an idempotent no-op rather than a rejection. Caught by pressing Acknowledge twice against the live server. What bounds the token is scope -- one incident, one action, one day -- not a use count.	2026-08-07 11:41:15 +02:00
Niklas Ye	7caafbaf80	chart: back up the database through a python sidecar ... The image is FROM scratch, so there is no interpreter to run a k8up backupcommand in, and the database runs in WAL mode, where a file-level copy of the volume is not crash-consistent. Also switches to strategy: Recreate. The data PVC is ReadWriteOnce, so a RollingUpdate deadlocks the new pod against the old one holding it. terdut-server-0.6.0 v0.6.0	2026-08-07 10:57:56 +02:00
Niklas Ye	bc285799d1	Page the on-call person when an incident opens ... An incident opened, got assigned to whoever held today's schedule entry, and then sat there silently until somebody thought to look. The schedule and the incident model were both built; nothing reached the person holding the pager. Notifications go out through ntfy, over plain HTTP with no new dependencies. Delivery is an outbox rather than an inline call: the pool is limited to a single connection, so a POST made while holding the webhook's transaction would stall every other request behind it. The webhook inserts a row and a notifier goroutine sends it within a tick, retrying with exponential backoff. Only opening an incident has to resolve a topic from scratch. Reminders and all-clears reuse whatever that first notification chose, which keeps configuration out of resolveIfSettled and gives the right rule for free: you only hear that something resolved if you were told it started. Each push carries an Acknowledge button, because the useful thing to do at 3am is stop the pager without unlocking anything. It POSTs to an unauthenticated /api/notify/ack/{token} — a notification body lives on the ntfy server and in the device cache, so a real API key must never appear in one. The token is minted per delivery, scoped to one incident and one action, and expires in a day. Reminders repeat until the incident stops being untouched. The stop conditions are the states that already mean somebody has it: acknowledged, snoozed, resolved, archived. Snooze is the mute button, so there is no separate reminder cap. Notifications sent to the fallback topic carry no Acknowledge button. The topic is shared, and a button on it would let any subscriber acknowledge as somebody else.	2026-08-07 08:51:38 +02:00
Niklas Ye	dcb2a86f9a	chart: bind the HTTPRoute to a named gateway listener ... The route carried no sectionName, so it attached to every listener whose hostname matched — including the hostname-less plaintext HTTP listener. On a publicly reachable hostname that means the API accepts bearer tokens over cleartext. networking.listener names the listener to bind to. It defaults to empty, which keeps the previous attach-to-all behaviour. Also document the Kubernetes install path, which the README omitted. terdut-server-0.5.0 v0.5.0	2026-08-06 12:01:13 +02:00
Niklas Ye	be739c319f	Check every push and pull request ... The release workflow gates a tag, which is the last possible moment: a commit that breaks the suite stayed green on main until somebody decided to publish, and then failed the release instead of the change that caused it. A CI workflow now runs go vet and go test on pushes to main and on pull requests. push is scoped to main rather than left open. A branch pushed as part of a pull request would otherwise be checked twice, and gh-pages carries the published chart index with no Go code in it, so go vet there would fail on a missing go.mod. Runs for the same ref cancel each other, since a rapid series of pushes only needs the last one checked.	2026-07-31 07:28:51 +02:00
Niklas Ye	28cf9faf77	Gate the release on vet and tests ... CI only ever built and published. The 44 tests in internal/api ran on a laptop or not at all, so a tag could publish binaries, a container image and a Helm chart from a commit whose tests had never been run — and the tests are the only thing holding several documented contracts in place, including the received_at heartbeat and the alert ordering guard. A test job now runs go vet and go test, and build, docker and chart all depend on it. The release job is downstream of build, so a tag that fails publishes nothing at all rather than publishing three artifacts out of four. chart-release.yml is deliberately left alone. It fires on charts/** pushes and publishes the chart, which contains no Go code and only references an image tag rather than building one, so gating it on the Go suite would add a minute to every chart edit for no signal. This still only runs at release time; nothing checks a push or a pull request, so a broken commit stays green until somebody tags it.	2026-07-31 07:23:14 +02:00
Niklas Ye	279ef6cf8b	Turn incoming alerts into incidents ... The alerts row was both Alertmanager's record and the human work queue, and the two have different owners. The webhook upsert rewrites that row on every notification; acknowledgement, comments and archiving were columns on it that the upsert happened not to touch. So an alert that resolved and re-fired days later still read as acknowledged by whoever acked the first occurrence — the ack outlived the thing it referred to. Nothing recorded transitions either: rows are mutated in place, so there was no timeline and no way to compute how long anything took. Alerts are now read-only signal records with two states, and incidents are the work item: triggered, acknowledged or resolved, with an assignee, a snooze, notes and an append-only timeline. Many alerts map to one incident, and a new occurrence opens a new incident, which is what makes a stale ack impossible rather than merely unlikely. Correlation uses Alertmanager's own groupKey. It already grouped the alerts according to the group_by routing tree the operator configured and sends the result on every webhook, where it was being discarded; adopting it means changing group_by in alertmanager.yml changes correlation here, with no second grouping scheme to configure and keep in sync. An incident opens only when an alert transitions into firing — an unseen fingerprint, a newer startsAt, or a resolved alert starting again. The unchanged notifications Alertmanager re-sends every repeat_interval are none of those. That rule is what lets manual resolution be terminal: without it, closing an incident by hand would be undone by the next re-send of an alert that never stopped firing, and the button would be a lie. Snooze covers the "not now" case instead. Incidents otherwise resolve by cascade, once every alert under them has stopped firing, whether by webhook or by expiry. New incidents are assigned to whoever holds today's schedule entry. The schedule table has existed since the first release with nothing reading it. Also here, following from the split: - Incident severity is a high-water mark over its alerts, never lowered. An incident that hit critical was a critical incident, and downgrading a live one would demote it in the queue while the work is still open. - /api/stats/incidents reports MTTA and MTTR, null rather than zero until there is something to average. Neither was computable before. - Alert archiving becomes sweeper-only housekeeping; the archive people interact with is the incident's. Breaking: the alert acknowledge, archive and comment endpoints are gone, and the alert object drops the acknowledgement fields and gains incident_id. The README maps each removed endpoint to its replacement. Migration 008 backfills an incident per existing alert, archived ones included so no comment is orphaned, carrying acknowledgements across and turning comments into timeline notes. Both documented alert contracts are untouched: received_at still advances on every accepted payload, re-sends included, and resolution_source still says how much to trust ends_at. The upsert is byte-for-byte what it was, now running inside the ingest transaction. terdut-server-0.4.0 v0.4.0	2026-07-30 17:02:13 +02:00
Niklas Ye	a602ff3efc	Document received_at and resolution_source as public contract ... The API reference listed endpoints but never the alert object's fields, so two of them were load-bearing for clients while being described nowhere. received_at appeared only in passing, as a stats filter; resolution_source only inside the stale-expiry prose. Both carry meaning a client cannot derive on its own. starts_at comes from Prometheus and never changes for an alert instance, so received_at is the only signal that a firing alert is still being refreshed — it advances on every accepted webhook, including the unchanged notifications Alertmanager re-sends every repeat_interval. resolution_source then says how much to trust ends_at: under 'alertmanager' it is an end time somebody reported, but under 'expiry' nothing ever reported one, so it is either a stale watermark or the sweep timestamp, and only an upper bound. README gains an alert object field table plus a contract section for each, including the nullability rules and the advice to tolerate unrecognised resolution_source values. The field comments in models.Alert now say these are public API rather than ingest details, and the upsert carries a note at the received_at line, which is where a regression would be introduced. Three tests lock the newly documented behaviour, none of which was covered before — the whole suite passed with the received_at bump deleted from the upsert, because the expiry tests only ever set that column via SQL: - a re-send advances received_at and leaves starts_at alone - a discarded out-of-order retry does not count as a heartbeat - an expiry resolve preserves a reported ends_at watermark and stamps sweep time only when none was known	2026-07-30 09:02:44 +02:00
Niklas Ye	79afd05ea5	chart: skip existing releases in chart-release workflow ... chart-release.yml fires on any charts/** push to main and ran chart-releaser against the committed Chart.yaml version, failing with 422 already_exists whenever that version was already published. A tagged release also publishes the chart from release.yml, which seds the version from the tag, so the two workflows raced and this one lost. Brings it to parity with the chart job in release.yml, which has carried skip_existing since 1451682.	2026-07-28 11:58:34 +02:00
Niklas Ye	42e846f876	Expire stale firing alerts ... A resolved webhook was the only path out of the firing state, so a notification that was dropped, silenced, or lost to a restart pinned an alert as firing forever — Prometheus showed it resolved while terdut-server kept listing it. The archiver only ever touched resolved alerts, and both the list and stats queries compared status with plain equality, so a stale row was indistinguishable from a live one. A sweeper pass now resolves firing alerts on either of two signals: the ends_at watermark Alertmanager sets on outgoing firing notifications has passed (plus a grace period for clock skew), or no webhook has refreshed the alert within TERDUT_STALE_AFTER (default 6h, above Alertmanager's 4h repeat_interval). Such alerts get resolution_source = 'expiry', distinguishing them from a real 'alertmanager' resolve. Two related webhook bugs fixed alongside: - The upsert had no ordering guard, so a retried firing notification arriving after the resolved one resurrected the alert. Payloads for an older alert instance are now discarded: a stale retry carries the same startsAt, a genuine re-fire a newer one. - archived_at was never cleared on re-fire, leaving a re-fired alert archived and invisible in the default list. Stats now exclude archived alerts to match the default list view; this lowers historical firing/resolved totals. The chart exposes both sweeper durations via sweeper.staleAfter and sweeper.archiveAfter. v0.3.0 terdut-server-0.3.0	2026-07-28 11:49:39 +02:00
Niklas Ye	debc4bf78c	Add alert archiving ... Alerts can be manually archived (POST /api/alerts/{id}/archive) or unarchived (DELETE /api/alerts/{id}/archive). A background goroutine auto-archives resolved alerts older than TERDUT_ARCHIVE_AFTER (default 7d). GET /api/alerts hides archived alerts by default; ?archived=true shows them. v0.2.0	2026-05-22 13:22:45 +02:00
Niklas Ye	36468a68ed	chart: add bootstrap job (v0.2.0) ... Post-install/post-upgrade Job that calls /api/bootstrap on first deploy and stores the admin API key in a Secret (<release>-admin-key by default). Exits cleanly on subsequent upgrades when bootstrap is already complete. Adds ServiceAccount, Role (secrets:create), and RoleBinding as hook resources. terdut-server-0.2.0	2026-05-22 10:11:30 +02:00