Vulture of the Future, test server

[Errant-4]

Description

As per the November 23 maintainer meeting, the following needs to be done for the test server

• There must be multiple clear indications in the lobby that it's a test server
• Bug report feature from ingame? (This should honestly be on every server) (Add an in-game button for reporting bugs. #7538)
• Copy the publish workflow and make it publish master daily
• configure master branch on RobustCDN?
• configure Vulture watchdog to use the master branch

[Errant-4]

Apparently only the first two are real issues and everything else should be a simple possibly tedious but probably not tricky chore?

We can already give the server a Message of the Day that will be displayed in chat when the player enters the lobby

#33783 will also allows us to put TEST SERVER (or any other similar messaging) in the lobby title

[BramvanZijp]

Will it be LRP or MRP, and will it be whitelisted or open to anybody?

[Errant-4]

I don't think anything has been suggested beyond just changing Vulture to run on the master branch, so it would be LRP and it would not be whitelisted

[FairlySadPanda]

Based.

For a test server I often see a banner being added to the client that says stuff like "THIS IS A TEST CLIENT" etc. Could be dismissable?

[Errant-4]

Based.

For a test server I often see a banner being added to the client that says stuff like "THIS IS A TEST CLIENT" etc. Could be dismissable?

What would this look like, can you show a sketch? The advantage of the stuff I have shown is that it's already possible or is in PR

[crazybrain23]

What would this look like, can you show a sketch? The advantage of the stuff I have shown is that it's already possible or is in PR

What if the commit hash was in the corner of the screen, near FPS?

[Coolsurf6]

Could you also list the PRs that are in testing? I know test-merges were a thing in SS13. This would be stated when first joining the server and link to the PR that is in testing.

[crazybrain23]

Could you also list the PRs that are in testing? I know test-merges were a thing in SS13. This would be stated when first joining the server and link to the PR that is in testing.

The test server will still have the changelog and due to how it works it'll be up to date.

[ArtisticRoomba]

Bumping this to promote the idea of the test server again. Having an entire playerbase test out new PRs as they're merged will be a hundred times better than a comparatively short maintainer meeting glossing over 25+ new commits on staging.

Ideally the commit hash is a watermark somewhere on the screen. That way it can easily be determined exactly what commit the server is running from screenshots or videos so there isn't any ambiguity as to what the server was running.

This will allow maintainers to easily catch and revert PRs that do more harm then good. For example it was nice to have new doors but the issues should have been caught and the PR reverted until it was good for a second merge. I'd say with 80+ people playing, it would have definitely been caught.

[Errant-4]

It was brought up that it could also be useful if the version number/commit hash was constantly displayed in a corner or something, small text. So it would automatically be there on every screenshot/recording made of the test server, for easier future handling of issues

[FairlySadPanda]

BUG REPORTING

STEP 1

Create a IBugReporter interface and a UserBugReport struct. The IBugReporter interface needs one function, public bool Report(UserBugReport). A "NoOpBugReporter" class implements IBugReporter, and does nothing. IBugReporter should be registered in the IoCManager for the server and by default return an instance of NoOpBugReporter.

STEP 2

Collar someone to do the frontend client work. The client needs to collect basic user data alongside a subject and body of a report. DO NOT BIKESHED THIS, JUST DO THE BARE MINIMUM. Send this data over the internet to the server, and have the server form this into a UserBugReport and sent to whatever implementation of IBugReporter is in use.

STEP 3

Write an implementation of IBugReporter that posts to a Github issue tracking repo. Create a server cvar that allows for the type of IBugReporter to be changed by server owners between different strategies.

STEP 4

Write an implementation of IBugReporter that reports to Sentry.

STEP 5

Get further requirements off of admins and maintainers.

[VasilisThePikachu]

STEP 4

Write an implementation of IBugReporter that reports to Sentry.

For anyone who is gonna work on this, Sentry support does not have to be added for the initial implementation and can be applied on a later date.

IMO, it should have a basic GitHub implementation at least to

1. Help anyone who wants to add other implementations (cough sentry. Or any other thing someone wants.)
2. Working system that's easy to set up for now.