Skip to content
Snippets Groups Projects
Select Git revision
  • f3031425ff4ecef6f9beba9aa15aa2d6b8ba742f
  • master default protected
2 results

transcript-generator

  • Clone with SSH
  • Clone with HTTPS
  • This is a new attempt to create a clean, standalone, webbased transcript generator

    Design

    The code that makes the app work lives in one repository. It get's build into a docker container for later consumption via the gitlab-ci. It shall also contain a minimal web server for accessing the web app.

    File layout code repo:

    ├── backend (Code for generating prefilled transcript)
    │   └── plugins (Core plugins that are included in the docker image)
    │       └── <pluginname> (a plugin folder)
    ├── docs
    └── webapp (svelte js code for the web frontend)

    In another repo lives the actual instance and config of such a web app. It is supposed to be cloned for each organisation intending to use it and then be customized to their liking. Secrets are expected to live in the GitLab CI config as environment variables.

    A config/intance repo should look like this:

    ├── templates
    │   ├── transcript.md
    │   └── topheader.md
    ├── config.yaml
    └── .gitlab-ci.yaml

    If non-core plugins are to be used, they should be cloned into the repo into the /plugins path. While looking for plugins, the program will first search in <repo>/plugins before falling back to /plugins where the core plugins are stored. This way custom plugins always take precedence.

    This separation into two repositores enables easy updates to the process: If you want to update a plugin, change it's version number in your config repo.

    Plugins

    Plugins are folders with an executable file called plugin and arbitrary other files needed for the plugin to work.

    Plugins are called by executing the plugin file in the folder with the plugins name (e.g. the plugin presence/gitlabprojectmembers/v1 would lead to the exeution of plugins/presence/gitlabprojectmembers/v1/plugin) The content of the transcript data (up to the point of the plugins execution) and the plugin's config is piped into the plugins stdin as JSON (encoded via JSON.stringify({transcript: transcript, config: pluginsConfig})). The output of the plugin is expected to be a valid transcript data object (validated against the json schema) and then handed over to the next plugin (if there is any). Secrets are to be sought in environment variables under the Namespace of the plugin (/ being replaced by _ to conform the usual env names according to the regex [a-zA-Z_]+[a-zA-Z0-9_]*).