DevOps - SC-SGS/surviving-sarntal GitHub Wiki

Purpose

This page aims to present dev ops aspects of the game development process.

Target Environment

Our target environment is a plain Ubuntu 24.04 LTS image with the necessary Dependencies installed.

CI/CD Pipeline

The pipeline consists of the following four steps:

  1. build: Builds the project.
  2. test: Executes all tests.
  3. lint: Checks code style and smells with clang-format and clang-tidy.
  4. run: A stub that pretends to run the game, effectively only checks whether an executable has been produced. Actually running the game on the server is not possible without a graphics and an audio device.

GitLab Runner

Having considered BWCloud as our first option for a GitLab Runner, we soon realized that there were other alternatives, better matching our needs. Our current GitLab Runner is hosted on an IONOS VServer, offering 1GB of RAM and 10GB of cloud memory.

Clang-format and Clang-tidy

We have established some code guidelines that are statically checked with clang-format and clang-tidy. While clang-format is mostly based on the LLVM template, the clang-tidy file is custom. It contains numerous checks, most notably for casing:

CheckOptions:
  readability-identifier-naming.ClassCase: CamelCase
  readability-identifier-naming.ClassMemberCase: camelBack
  readability-identifier-naming.VariableCase: camelBack
  readability-identifier-naming.FunctionCase: camelBack
  readability-identifier-naming.MethodCase: camelBack
  readability-identifier-naming.EnumCase: CamelCase
  readability-identifier-naming.EnumConstantCase: UPPER_CASE
  readability-identifier-naming.ConstexprVariableCase: UPPER_CASE
  readability-identifier-length.MinimumVariableNameLength: 3
  readability-identifier-length.MaximumVariableNameLength: 35
  readability-function-size.LineThreshold: 30
  readability-function-size.NestingThreshold: 4

Commit Hooks

In addition to the pipeline, the code base is kept clean with commit hooks, running clang-format and clang-tidy on the changed files and blocking a commit locally if the changes do not adhere to our guidelines. This redundancy might seem strict at first, but it has helped us keep the code quality high even when the runner for the pipeline was down.

Code Documentation: Doxygen

Since GitLab pages is not available to us in this self-hosted version, and we do not want to keep the created docs in our repo, we instead offer a generate_docs.sh script that creates the documentaion. From the root directory, simply run

source build-utils/generate_docs.sh

If you do not have doxygen installed, you will be prompted to confirm the script installing it for you. The generated docs can be found in the ./docs directory. To view it, open ./docs/html/index.html in your favorite browser or generate a refman.pdf using

cd docs/latex
make