Skip to main content

GitHub Workflows

Introduction

The repository comes with a few GitHub Workflows preconfigured. This page contains a description for each workflow and a note on when it gets triggered. If you want to fork the repository please refer to the fork page.

Code Quality

TriggerBranches
Pull RequestAll
Pushmain, stable

Required to merge pull request: Yes

This workflow has three jobs:

  • Type Check Client: Checks if the client compiles and does not contain any type errors.
  • Type Check Server: Checks if the server compiles and does not contain any type errors.
  • Code Quality: Checks all projects inside this repository if their code complies to the code styles configured in this repository.

Unit Tests

TriggerBranches
Pull RequestAll
Pushmain, stable

Required to merge pull request: Yes

Runs the unit tests in the server.

Build and push Docker image

TriggerState
Releasepublished

Required to merge pull request: No

If a release is published (not drafted or updated) this job will create a new docker image. The version used is the tag of the release. After the image is created it gets pushed to the GitHub Container Registry associated with this repository.

Semantic version

Make sure the version tag of your releases match the semantic versioning: major.minor.patch

Deploy docs

TriggerBranches
Pull Requestmain
Pushmain

Required to merge pull request: Yes

In a pull request made against the main branch one job of the workflow checks if this documentation could be build. Due to the second job being skipped in pull requests it shows so inside the CI box at the bottom of the pull request.

Everytime something is pushed to the main branch of the repository this documentation gets build with the second job. Afterwards it gets pushed to the corresponding GitHub pages branch of the repository. If you push against the main branch of a fork the docs get updated inside the fork not the original repository.