---
# System prepended metadata

title: Goonstation Test Merges

---

# Goonstation Test Merges

## Abstract

Test Merges are a feature that allows servers to 'test' merging PRs by temporarily including them in the game code. By doing this, you don't have to actually merge the change, and you can test it live without fear of merging it into the actual game code and dealing with conflicts and more. This is also good for temporary urgent fixes while working on a better solution.

## Goals

* Easy to mark PRs as valid for test merging on the server
* Not break when PRs would conflict
* Mark in logs and to players ingame which PRs are merged (for bug reporting and admin use)

## Non-Goals
* Making this a security risk
* Replacing event branches for big event-like things, as PRs are public and branches are simpler

## Implementation
* When a new server build is triggered, the following is done:
    1. Reset to the latest commit on the branch as normal.
    1. If test merging is disabled on the server, skip all of this.
    2. The list of valid test merge PRs is retrieved from the database, if there are zero, abort to normal
    5. One by one, PRs are attempted to be merged:
        * Note that the specific commit specified in the DB is the one to merge
        * If merging a PR generates a conflict, skip that
            * https://stackoverflow.com/a/501461
            * Ideally, this would be reported in #deployments - bonus points for the actual merge conflict
    1. Data of *successfully merged* PRs is compiled and stored in a way. This could either be injected via defines, put in a file that is read, or another API route.

* When ingame, the following is done:
    * The changelog shows test merged PRs with their changelogs in a visually different style or section.
    * The bug report form automatically notates the test merged PRs in the body
    * The game/admin logs show which PRs are testmerged at the top

* API routes for the commands below

## Database Structure
Something like the following, where the PR number is documented, which server/group it's valid for, the id of the discord user who submitted the request, and the commit at time of addition/update.
```
CREATE TABLE `Testmerges` (
	`PR` INT(8) NOT NULL,
	`Server` TEXT(20) CHARACTER SET utf8 COLLATE utf8_general_ci,
	`Requester` TEXT(30) CHARACTER SET utf8 COLLATE utf8_general_ci,
	`Commit` TEXT(40) CHARACTER SET utf8 COLLATE utf8_general_ci,
	PRIMARY KEY (`PR`)
);
```

## Command Syntax

`/ci testmerge list`
Shows a dashboard/table of all current testmerges.
This could honestly be public access maybe.

`/ci testmerge merge <pr> <server/group> (commit)`
This will add a given PR to the database with the info.
If a **full hash** is specified, it uses that instead.
Ideally this would have a confirm/cancel button.

`/ci testmerge update <pr> (server/group) (commit)`
This updates an actively testmerged PR to the latest commit (the HEAD).
If a **full hash** is specified, it uses that instead.
By default, all 'instances' of the PR  in the database are updated.

`/ci testmerge cancel <pr> (server/group)`
Removes the testmerge from the database, all servers by default or specified
Ideally this would have a confirm/cancel button.


## Alternatives

Labels automatically merge: doesn't work because of RCE, or is just the same amount of work. If putting the label on a PR will just fetch the latest commit on the PR branch, someone can put a label on and then the contrib can sneak shit in. If it doesn't autoupdate, then what's the point.