issue-tracker: The Serverless QA Department
How a massive closed-source gaming project uses YAML forms and Regex logic to turn a standard GitHub repository into an automated triage pipeline.
- Plutonium leverages strict YAML forms to eliminate unstructured bug reports and force users into a categorized triage pipeline.
- A custom GitHub Action uses Regex and array logic to intelligently infer master labels from multi-engine dropdown selections.
- The project maintains a strict closed-source core to prevent code theft while utilizing an open-source intake valve for community QA.
The Multi-Engine QA Nightmare
The Plutonium Project is not a standard software application. It is a massive community-driven framework providing custom clients, dedicated servers, and anti-cheat for four older Call of Duty titles. Managing bug reports across distinct game engines built decades apart requires ruthless organization. When users simply type "my game crashed" into a Discord channel, triage becomes impossible.
To solve this, the volunteer team weaponized a single open-source meta-repository. They did not build a custom backend. Instead, they turned standard GitHub Issues into a fully automated, multi-engine triage pipeline.
Banning the Blank Issue
The first step in building this pipeline was eliminating the free-form text box. The repository configuration explicitly sets blank_issues_enabled: false. This is a high-friction design decision that forces users into a structured workflow.
The team uses GitHub's YAML issue templates to define strict forms. By utilizing type: dropdown and explicitly requiring selections, they force users to categorize their own bugs by engine (like T6MP for Black Ops 2 Multiplayer) before submission.
body:
- type: dropdown
id: games
attributes:
label: Affected game(s)
multiple: true
options:
- T6MP
- T6ZM
- IW5MP
- T4MP
- T4SP
validations:
required: true
The Regex Triage Engine
The real magic happens the moment an issue is submitted. A GitHub Action script written in Node.js immediately parses the incoming Markdown body. This script serves as the inference engine for the entire QA process.
The script uses Regex to extract the values selected in the YAML dropdowns. It maps these human-readable strings to internal tags. More importantly, it performs logical checks to infer broader categories. If a user selects both "T6ZM" and "T4SP" (both Zombies modes), the script intelligently applies a master "Zombies" label.
// Extracting and evaluating the selected games
const gameRegex = /### Affected game\(s\)\s*(.*)/;
// ... parsing logic ...
if (games.every(g => g.includes('MP'))) {
labelsToAdd.add(mpLabel);
}
else if (games.every(g => g.includes('ZM') || g.includes('SP'))) {
labelsToAdd.add(zmLabel);
}
The Open Intake for a Closed Core
This highly structured open-source repository stands in stark contrast to the Plutonium core client itself. The actual C++ framework that powers the custom servers and anti-cheat is strictly closed-source. This is a deliberate architectural segregation.
While fully open-source mod clients like Titanfall 2's Northstar encourage broad code contributions, Plutonium restricts access to prevent malicious forks and code theft within their specific ecosystem. The issue tracker allows them to maintain that security posture while still processing community feedback at scale.
The sad state of the CoD "Community" which copy pastes your code and tries to sell it off as their own. Sometimes figuratively, sometimes literally. We had an experiment going some time ago where a module largely written by a single dev was released as open source, they literally slapped a gui on top and started selling it...