Skip to content

it-at-m/riski

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

986 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

RIS-KI

Find information in munich's political information system RIS with the help of ai.

Project Information

Made with love by it@M GitHub license

Technology Stack

Supported python versions Supported npm versions uv FastAPI vue Postgres LangGraph

Build Status

Backend tests

Container Images

Extractor Backend Document Pipeline Frontend

Getting started

The quickest way to try RIS-KI locally is to start the shared database with Compose, seed it with example data via the extractor, and (optionally) run the document pipeline.

Prerequisites

  • Docker or Podman (the repo ships a root-level compose.yaml)
  • Python toolchain (we recommend uv)
  • A populated .env in the repo root (see .env.example for the variables used by all services)

1) Start the stack via Compose

One-time setup (required before the first backend start) to create the Kafka topics:

podman compose --profile init up topic-init

From the repository root you can start everything (DB, Adminer, Kafka, backend, gateway, frontend) with:

podman compose up -d

Defaults for Postgres (from compose.yaml): user postgres, password password, database example_db, exposed on 5432.

2) (Optional) Seed with sample data

To populate the database with sample data from Munich's RIS and process documents with OCR, run the initialization services:

podman compose --profile init up

This will:

  • Create necessary Kafka topics
  • Extract sample entities and files from the configured RIS endpoint (honors your .env, e.g., date range and base URL)
  • Run OCR on documents and store extracted markdown (configure OCR variables like RISKI__DOCUMENTS__MAX_DOCUMENTS_TO_PROCESS and RISKI__DOCUMENTS__OCR_MODEL_NAME in your .env)

3) Access the application

Once the stack is running, visit:

Roadmap

See the open issues for a full list of proposed features (and known issues).

Documentation

Development

Releasing backend or extractor images

Use the tag-version.ps1 helper to create semantic tags that trigger the GitHub Actions workflows responsible for building the container images.

./tag-version.ps1
  1. Select the service (backend, extractor, frontend, or document-pipeline).
  2. Choose the version bump (major, minor, or patch).
  3. When prompted, decide whether the script should also bump the detected manifest (for example riski-backend/pyproject.toml, riski-extractor/pyproject.toml, riski-document-pipeline/pyproject.toml, or riski-frontend/package.json) to the same version. This keeps the package metadata, container tags, and badges in sync.
  4. Confirm the suggested tag (for example backend-1.2.0, extractor-1.2.0, document-pipeline-1.2.0, or riski-frontend-1.2.0).
  5. Confirm pushing the tag to origin to start the corresponding Docker release workflow.

After a successful push, the workflow builds and publishes the image to GitHub Container Registry.

Syncing riski-core changes into other services

The Python services (riski-backend, riski-document-pipeline, riski-extractor) import the local riski-core package via path dependencies. Whenever you change riski-core, rerun the dependency install inside each consumer so uv rebuilds the local package:

uv sync --reinstall-package core

Run the command from the respective service folder (for example riski-backend) so uv picks up the correct pyproject.toml.

Contributing

Contributions are what make the open source community such an amazing place to learn, inspire, and create. Any contributions you make are greatly appreciated.

If you have a suggestion that would make this better, please open an issue with the tag "enhancement", fork the repo and create a pull request. You can also simply open an issue with the tag "enhancement". Don't forget to give the project a star! Thanks again!

  1. Open an issue with the tag "enhancement"
  2. Fork the Project
  3. Create your Feature Branch (git checkout -b feature/AmazingFeature)
  4. Commit your Changes (git commit -m 'Add some AmazingFeature')
  5. Push to the Branch (git push origin feature/AmazingFeature)
  6. Open a Pull Request

More about this in the CODE_OF_CONDUCT file.

License

Distributed under the MIT License. See LICENSE file for more information.

Contact

it@M - kicc@muenchen.de

Packages

 
 
 

Contributors