Repository navigation
feat:docs as sphinx - #369
Merged
Merged
Conversation
`sphinx-build -W --keep-going`: a broken cross-reference is a warning, and in docs it is a bug, so the build fails on it while still reporting every warning. The venv is synced with `uv sync --locked` on every run instead of only when it is missing, so a stale venv cannot build with old versions and a lock out of step with pyproject.toml fails.
User documentation lives in docs/ as its own component: Sphinx with Markdown (MyST) and the Furo theme. `just docs::build` builds it like CI will, failing on any warning; `just docs::serve` previews it with live reload. Every page carries a banner naming the version it describes, worked out by the same rule as the app's footer (v0.11.0 on a clean release tag, v0.11.0+<commit> otherwise): the published docs follow main, and production can run an earlier release.
…nshots `just docs::screenshots <page>...` (or --all) logs in to the local stack through Keycloak as a seeded user, opens the hackathon from the dashboard, clicks the sidebar entry and saves the first screen to docs/src/static/screenshots/<page>.png. It ends by listing which pictures changed, so you know which doc pages to reread. It only runs when asked; nothing in CI takes screenshots. docs/screenshots.toml names, per page, the sidebar entry, the login and the seeded hackathon where that entry exists. Sidebar links now carry `data-nav-id`, which the script clicks: an id outlives a renamed label, and a missing entry fails loudly instead of photographing the wrong page. Playwright sits in its own dependency group, so the docs build never installs a browser.
sabinem
force-pushed
the
feat/docs-sphinx
branch
from
October 22, 2026 12:28
caf184a to
375b66e
Compare
One doc page per entry of a hackathon's sidebar, named after the entry's id (manage:teams is owner/manage-teams.md), each with its screenshot from `just docs::screenshots`: twelve for owners, eight for participants. The Settings page explains the capability checkboxes step by step and links each one to the pages it affects. A frontend test fails when a sidebar entry has no doc page or no entry in docs/screenshots.toml, so the docs cannot silently fall behind the navigation.
The ci job builds docs/ like the other components, so a broken link or page fails the PR. A new docs job publishes the site to GitHub Pages on pushes to main; it alone gets pages/id-token write, and deployments queue rather than cancel each other. It fetches full history so the version on every page can see the release tags. Pages must be enabled in the repository settings with "GitHub Actions" as the source before the first merge.
sabinem
force-pushed
the
feat/docs-sphinx
branch
from
October 22, 2026 13:03
375b66e to
7e7ad9a
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hackathon owners and participants can now read how the platform works
User Story: As someone running a hackathon, I want to look up what a page or a checkbox does, so that I don't open voting by accident or leave participants unable to see their own team. Until now there was no documentation at all. The Settings page in particular was confusing: moving to the next phase opens nothing, and the effect of each checkbox was easy to misread.
Now there is a documentation site, published to GitHub Pages from main. It has a guide for owners and one for participants. Every entry in a hackathon's menu has its own page with a screenshot. The Settings page goes through the checkboxes step by step and links each one to the pages it affects.
Deliberately left out:
Next step:
Verified: