Fediversity Panel

Flake attributes

The flake outputs the panel entrypoint (./panel#...) exposes. This page is generated from the entrypoint itself every time the docs are built, so it always reflects the current outputs. Descriptions come from each attribute's meta.description.

Two kinds of attribute

The generated lists at the end of this page are panel/'s own leaf outputs: the Django package, the forms-island bundle, the generated openapi-client, the checks. They are not the whole of ./panel#.

Alongside them the entrypoint carries a deploy family: a full set of <group>-<effect>-<machine> attributes that provision the hosting-provider machines with BOTH the api and panel services registered. This is the full mono-repo composition, and the repo-root default.nix re-exports exactly this family as its top-level deploy attributes (with the authoritative whole-repo pin baked in). So at the repository root:

nix run '.#<group>-<effect>-<machine>'   # resolves to panel's deploy family

or against the leaf directly:

nix run './panel#apps.<group>-<effect>-<machine>'

How the two sets combine:

  • apps, nixosConfigurations and deploymentAttributeNames come verbatim from the rendered deploy family.
  • packages and devShells are deploy.<x> // <panel's own>, so panel/'s leaf attributes win. The deploy names are all group- and effect-prefixed, so they sit alongside the flat leaf names without collision; the single overlap is devShells.default, which stays the panel devShell.

The names follow core's grammar

panel/ does not invent attribute names: they follow core's <group>-<effect>-<machine>[-<verb>] grammar exactly, described at https://core.pages.git.fediversity.eu/flake-attributes.html. The derivations differ, because this family is rendered from a group set that has both api/ and panel/ folded in, but the naming, the all/combined aggregate targets and the verbs are the same. They are not enumerated here: the family is on the order of a thousand attributes, and core's page documents the pattern rather than the list. For the flat enumeration:

nix eval --json ./panel#deploymentAttributeNames

How it is built (and how to extend it)

panel/ maintains no deployment topology of its own. It reuses core's pure render combinator. Rather than re-fold api's application onto the frontend-free base itself, panel/ extends api's pre-extended group (api.lib.composedGroups, which is base + api's application) with only its OWN application, then re-renders:

core = import ../core { inherit system sources pkgs; };
apiLeaf = import ../api { inherit system sources pkgs; };
composedGroups = core.lib.foldGroupComponents apiLeaf.lib.composedGroups {
  hosting-provider = [ component ];  # panel's own fragment only
};
deploy = core.lib.render { inherit system sources groups = composedGroups; };

core is downward-only (it never names a front-end leaf), so this fold happens in the leaf, by name (panel -> api -> core, acyclic). foldGroupComponents appends, so folding [panel] onto api's already-[...base, api] group reproduces the exact [...base, api, panel] merge order -- hence a byte-identical deploy -- that a single [api, panel] fold produced.

A downstream extends the model the same way -- onto api.lib.composedGroups to keep api/ registered, or onto core.lib.baseGroups to stay api-independent. No fork of core. Both routes are spelled out at https://api.pages.git.fediversity.eu/flake-attributes.html.

Packages

  • centrifugo-dev
  • db-diagram
  • default
  • docs
  • docs-with-screenshots
  • manage
  • openapi-client: Generated Python client for the fediversity-api HTTP surface
  • screenshots

Checks

  • apps-panel: Deploy applications through the panel web UI and verify the result.
  • panel-api-frontend: Assert the panel composition gives the api node the origin, the authorization callback, the callback token and the events domain of the panel, that the AsyncAPI page of the api node names that events domain, that no file of the panel node states the tester apex, that no check of the panel imports a file of core by path, that no check or NixOS test of the panel imports a file of api by path, and that the database backups of the panel and of the api node prune with backupRetention.application (30 days) and read a repository password that their own node generates.
  • panel-basic: Smoke-test the operator panel (Django) boots and serves.
  • panel-db-diagram: Render the entity-relationship diagram of the panel's migrated database.
  • panel-docs
  • panel-js-tests: Run the panel's browser-script unit tests under node, with no browser.
  • panel-migrations: Check the panel's Django migrations are complete and apply cleanly.
  • panel-plan-data: Assert the plan of each node of the composed hosting-provider group, with the api and panel nodes, holds only data and is unchanged through JSON.
  • panel-python-tests: Run the panel's Django test suite against sqlite, with no VM.
  • panel-screenshots: Capture the documentation screenshots from the panel web UI, and check each page it visits with axe-core for violations of WCAG 2.1 level AA.
  • panel-state-migrations: NixOS test of the guard on the version of the panel database: a fresh installation records the number of the last migration of the panel app without a dump, an upgrade dumps the database through the backup command of the streamingBackup contract and keeps only that dump, and a downgrade is refused with exit status 78 while the panel stays stopped and the data stays.
  • treefmt: Check that the project tree is formatted