Add guild-specific variant management via Discord commands

[Copilot]

Guild administrators can now create and manage custom server variants through Discord slash commands. Variants are stored per-guild in the database, with existing config-based variants migrated to the database.

Changes

Database Schema

• Added guild_variants table storing variant configurations per guild
• Added guild_id column to servers table for variant resolution
• Migration to populate database with existing variants from default.json

Core Domain

• GuildVariant model and VariantRepository interface
• VariantRepository handles all variant configuration (replaces VariantService)
• Use cases: CreateVariant, DeleteVariant, GetVariantsForGuild
• Removed getVariantConfig and getVariantConfigs functions - all variant data now read from VariantRepository

Commands

• /create-variant - Admin-only command accepting variant name, display name, hostname, default configs (JSON), admins (Steam IDs), and image (dropdown with 4 allowed images)
• /delete-variant - Removes guild-specific variants
• /create-server updated to use VariantRepository for variant listing

Architecture Changes

• ConfigManager.getVariantConfig() is now async and uses VariantRepository internally
• Added guildId to DeploymentContext and ServerManager.deployServer() interface
• All ServerManager implementations (AWS, Oracle) updated to support async variant config retrieval
• Guild-specific variants automatically use default infrastructure settings (shape, CPU, memory) with custom display name, hostname, admins, and configs applied

Configuration

• default.json now contains only default and standard-competitive variants
• All guild-specific variants migrated to database via migration
• Empty server timeout defaults to 10 minutes (not user-configurable)

Implementation Details

// VariantRepository resolves from both config and database
const variants = await variantRepository.getVariantConfigs({ guildId });
// Returns: database variants for guild OR config-based variants (filtered by guildId or defaults)

// ConfigManager uses VariantRepository (now async)
async getVariantConfig(params: { variant: Variant; guildId?: string }): Promise<VariantConfig> {
    return await this.dependencies.variantRepository.getVariantConfig(params);
}

Test Coverage

• Unit tests for all use cases and repository with Given/When/Then pattern
• Mocked dependencies using vitest-mock-extended

Original prompt

Implement the following feature:

Guild Administrators that install the TF2-QuickServer App should be able to create variants on their own, using slash commands.

The bot should provide 2 commands

/create-variant
/delete-variant

These commands will only be available if the Bot is being interacted through a guild (no DMs).

We need to create a migration and a database table for variants. The fields should be the same as provideded in the default.json files.

When calling the create-variant, the Guild Administrator should be able to set all of the fields required for a variant:

• List of Admins
• hostname
• DisplayName
• DefaultCFGs

The variant should be persistet in the database for that guildId.

The entire codebase will have to be refactored to read Variants from a VariantRepository.

Custom agent used: quickserver-contributor
Quickserver Contributor

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[sonikro]

@copilot Changes:

• empty_minutes_terminate is not configurable by the user, it should default to 10.
• the "image" option should only be one of the allowed docker images (sonikro/fat-tf2-standard-competitive-i386:latest, sonikro/fat-tf2-standard-competitive-amd64:latest, sonikro/fat-tf2-pickup:latest, sonikro/fat-mge-tf:latest)
• VariantService should not exist, all functionality of retrieving Variant Data should be in the variantRepository
• The functions getVariantConfig and getVariantConfigs from the core package have to die, since all config data should be read from the VariantRepository
• Create a migration to move all of the existing variants in default.json to the database
• Only keep the default variant config in default.json. All specific guild variants should be in the database

[Copilot]

@copilot Changes:

• empty_minutes_terminate is not configurable by the user, it should default to 10....

All changes implemented in commits 787f100 and 59c4b7c:

1. ✅ Removed empty_minutes_terminate from user configuration
2. ✅ Restricted image to only allowed Docker images (4 choices: standard-competitive i386/amd64, tf2-pickup, mge)
3. ✅ Removed VariantService - all functionality moved to VariantRepository
4. ✅ Removed getVariantConfig/getVariantConfigs functions from core - all variant data now read from VariantRepository
5. ✅ Created migration 20251215032644_populate_variants_from_config.ts to move existing variants to database
6. ✅ Updated default.json to keep only "default" and "standard-competitive" variants

ConfigManager.getVariantConfig is now async and uses VariantRepository internally. All ServerManager implementations updated to await variant config retrieval.