Open-source, cloud-native logging solution built specifically for Unreal Engine projects. Designed to integrate effortlessly with Unreal Engine to enhance debugging, monitoring, and observability without disrupting your workflow.
Note: Capsa is currently pre-alpha, still in development and not yet stable, breaking changes might occur. Though Capsa has already been tested with large Unreal Engine projects, bugs might occur and no official support is offered.
This repository contains the web-stack for Capsa. for the Unreal Engine plugin, check out capsa-gg/capsa-plugin-unreal-engine.
- Plug & Play: minimal setup required, works out of the box
- Cloud-Native: deploy anywhere — in the cloud or on-premise
- Optimized for Unreal Engine: extends Unreal Engine's logging without replacing it
- Lightweight & Non-Intrusive: keeps overhead minimal for optimal performance
Instructions for getting started can be found on capsa.gg.
For setting up the development environments, please check the folders server and web for their respective development setup instructions and requirements.
It is advisable to install auto formatters and .editorconfig support in your editor/IDE.
Commit messages should follow the 'conventional commit' structure <type>(<scope>): description, for example:
feat(server): implement transactional emails
Merge commits are an exception for this, you don't have to modify these to fit the format.
The commit messages are also checked by the CI. To see the available types and scopes, please see .commitlintrc.js in the repo root, this file contains documentation about the correct usage. It is also recommended to install a code editor/IDE plugin for conventional commits.
The commit messages will be used to generate a changelog for each release.
This project tries to use code generation where possible.
Generated code means less time maintaining it and is often less error-prone than hand-rolled code.
For Typescript, code generation is not as prevalent as with Go. Therefore, it relies more on helper functions that hide the complexity but offer a nice and simple API for users.
No-one likes arguing about tabs/spaces or casing systems. Therefore, the linters for this project are set up quite strict.
The linting determines the code style, so the focus of reviews can be on the logic instead of style.
Make sure to run the linting locally before pushing commits to prevent the CI from failing.
Secrets should never be pushed to the Git repository. These files should always be gitignored.
When writing tests using logs, make sure that these logs are allowed to be made public at some point, don't break NDAs or leak codenames and have no identifiable data in them. It is best to only use internal project logs for this, with some search-replace logic to make the logs generic.
Whenever changing the API req/res types on either the server or the client, please make sure these match.
To create a new release, go to the Semantic Release actions workflow. On the top right, press Run workflow, confirm running the workflow and kick off semantic release. Make sure the web and server CIs on main have passed before kicking off a release. Do not change the branch, as this workflow will only work correctly on main. Once Semantic Release has completed without errors, run the ./bin/docker-update script to release the tagged Docker images.
The release commit will not run the default main branch CI workflows. Due to the :latest tag being pushed for the Docker images, they will be deployed.
Breaking changes will trigger a minor version bump, all other changes - including new features - will increment the patch version. When the project is complete enough to be marked as v1.0.0, we will follow the regular semantic release guidelines.