CI Pipeline & Linters
Relevant source files
The following files were used as context for generating this wiki page:
The Continuous Integration (CI) pipeline and linters automate the verification of code quality, asset integrity, and gameplay stability. The system enforces coding standards, detects anti-patterns in map files, manages flaky test scenarios, and provides visual feedback for UI changes. These tools ensure that every Pull Request (PR) meets the project's technical requirements before merging.
Sources: README.md:1-5, tools/ci/check_grep.sh:1-10
Automated Linting Systems
The project employs several specialized scripts to perform static analysis on DM code, map files, and preprocessor defines.
DM Grep Linter
The check_grep.sh script uses ripgrep (or standard grep) to scan the codebase for common mistakes, outdated syntax, and formatting issues. It enforces specific rules for code and map files.
| Category | Check Performed | Error Trigger |
|---|---|---|
| Map Issues | TGM Format | Detects non-TGM formatted map files. |
| Whitespace | Indentation | Detects space indentation; requires tabs. |
| Common Mistakes | Global Vars | Detects unmanaged global variable usage. |
| Syntax | 516 Href | Requires internal links to start with byond://. |
| Sanity | forceMove | Validates forceMove() argument count. |
Sources: tools/ci/check_grep.sh:54-250
Define Sanity Check
The check.py script ensures that local preprocessor #define statements are properly #undefed within the same file. This prevents macro leakage across the compilation tree. Certain directories like code/__DEFINES and modular_bandastation are exempt from this local undef requirement.
Sources: tools/define_sanity/check.py:30-45, tools/define_sanity/check.py:80-90
Maplint
Maplint prohibits anti-patterns in .dmm files using YAML-based rules. It allows developers to ban specific typepaths, variable edits, or object combinations on the same tile.
The diagram shows how Maplint processes map files against defined YAML constraints to find illegal mappings.
Sources: tools/maplint/README.md:1-50
Testing Infrastructure
Testing is divided into unit tests and visual regression tests to verify both logic and appearance.
Unit Tests
Unit tests are automated procedures that verify game mechanics. They are implemented as subtypes of /datum/unit_test and must override the Run() proc.
- Assertions: Use macros like
TEST_ASSERT_EQUAL(a, b)orTEST_ASSERT_NOTNULL(a). - Allocation: The
allocate(type, ...)function creates temporary objects that are automatically cleaned up after the test completes.
Sources: code/modules/unit_tests/README.md:10-35, code/modules/unit_tests/README.md:70-90
Screenshot Tests
The screenshot test pipeline captures UI and icon states to detect unintended visual changes. If a test fails, the system generates a diff image and provides a comment on the PR with instructions for fixing or updating the baseline.
This sequence illustrates the automated reporting flow for failing visual tests.
Sources: tools/ci/show_screenshot_test_results.js:70-150
PR Lifecycle Management
The CI system manages Pull Requests through automated labeling and error recovery.
Automated Labeling
The autoLabel.js script dynamically assigns labels based on PR metadata.
- Changelog Parsing: Scans the
:cl:block for keywords to apply labels likeBugfixorQoL. - File diffs: Inspects changed file extensions (e.g.,
.dmmfor mapping labels). - Conflict Detection: Polls GitHub for mergeability and applies the
Merge Conflictlabel if necessary.
Sources: tools/pull_request_hooks/autoLabel.js:50-120, tools/pull_request_hooks/autoLabel.js:200-240
Flaky Test Management
Flaky tests (tests that fail inconsistently) are handled by rerunFlakyTests.js.
- Detection: It monitors jobs like "Integration Tests" or "Alternate Tests".
- Action: If a failure is detected in a "designated flaky" job, the script automatically triggers a workflow rerun.
- Reporting: If the test fails twice, it extracts the error (e.g., a specific runtime or hard delete timeout) and creates/updates a "🤖 Flaky Test Report" issue.
Sources: tools/pull_request_hooks/rerunFlakyTests.js:5-30, tools/pull_request_hooks/rerunFlakyTests.js:150-200
TGUI Build and Linting
The TGUI framework includes its own set of checks using Bun and Biome.
- tgui-lint: Uses Biome to format code and find potential bugs in Javascript/JSX.
- tgui-tsc: Performs type-checking with the TypeScript compiler.
- tgui-test: Executes unit and integration tests specifically for the UI.
Sources: tgui/README.md:50-80, biome.json:40-70
The CI Pipeline & Linters provide a multi-layered defense against regressions. By combining grep-based checks, preprocessor validation, map-specific rules, and automated test reruns, the project maintains high code standards and reduces the manual burden on maintainers during the PR review process.