I don’t have any major updates this month due to life taking over a bit.

Highlights

• Finalized my Perforce setup
• Finalized my TeamCity build configurations for testing and beta deployments
• Tossed in some of my favorite plugins

Perforce Setup

The first thing I did with my Perforce server was deploy it back to my Synology NAS. I created a nice little docker compose file that you can use to easily deploy this to your own server. below is a snippet from my docker-compose file that I use to deploy Youtrack, TeamCity, mysql and Perforce.

version: "3"
services:
  perforce:
    container_name: perforce
    platform: linux/amd64
    image: hawkmothstudio/helix-p4d:1.3
    environment:
      - P4PORT=${P4PORT}
      - P4USER=${P4USER}
      - P4PASSWD=${P4PASSWD}
    ports:
      - 1666:1666
    volumes:
      - ${CONFIG_PATH}/perforce:/data
    restart: unless-stopped
    deploy:
      restart_policy:
        condition: on-failure

To use this you need to set the following environment variables

P4PORT= // The address for the perforce server.  If you omit this the docker container will set you up ssl::1666 which will enable ssl and listen on local connections
P4USER= // The admin user
P4PASSWD= // The admin password
CONFIG_PATH= // The folder where you want to store all of the data for the container

Backup

One thing I always struggled with when it comes to Perforce was backing up the data. With Docker, you can just stop the server, copy the CONFIG_PATH folder and store it somewhere. I did not want to do this because this method also copies revisions of files.

Since I’m a small shop and I don’t foresee myself having to need months of historical revisions, I wanted a method that would just copy the most recent revisions of all of my streams. The steps are a bit specific to my setup since I’m saving the backup on my local file server that will then sync it to Synology C2.

You don’t have to use Windows to do this but I preferred to run this on windows since the setup was more straightforward to me than setting up a NFS client to connect to my file server.

This build is ran inside of the mcr.microsoft.com/windows/servercore:ltsc2022 docker container. Here’s the batch script

net use Z: \\%SERVER_LOCATION%\backups\%ARCHIVE_DIR% /user:%DDC_USER% %DDC_PASS%
tar -czf %system.teamcity.build.tempDir%\%teamcity.build.branch%.tar.gz .
xcopy %system.teamcity.build.tempDir%\%teamcity.build.branch%.tar.gz Z:\ /Y

What this does is mount a network share to Z:. The DDC_USER and DDC_PASS are the username and password of the fileshare that you’re trying to connect to. The tar command will create an archive of the current working directory. The first parameter is the place to store the file and the second command is the folder to create an archive for. The xcopy will then copy the archive to the network share and the /Y switch is to overwrite the file if it already exists

The last thing to do is set up a trigger. Jenkins is a bit annoying with the Perforce plugin that they have. The TeamCity trigger is quite nice, I have this setup to run every Sunday at 12am and it will back up every stream that has any new changes since the last time it was ran.

Pipeline

The current pipeline that I’m using for the project consists of these steps. I broke each one down further in these posts

All of the following configs are ran in Windows except the Windows Steam config. This uses the contentful builder in linux to make the deployment

• Backup - described in the section above
• Build All - A composite build that aggregates the results for my test and build pipeline. The goal of this was to easily run multiple builds with a click of a single button and see them all together.
• Deploy All - Similar to the build all config, except this handles multiple deployments. Currently I’m just deploying to Steam, plan to be doing Epic Games as well
• Fill DDC - To speed up builds I fill my Derived Data Cache before running build configs. This is ran whenever I use the Deploy All config or on a CRON schedule for Monday and Thursday. My local PC also uses the same DDC so it speeds up development for me as well
• Test - Runs my functional test. At the moment LinterV2 does not work for 5.2.1 so I can’t lint my blueprints anymore. I plan on creating my own linter in the future to replace this plugin once my project picks up speed
• Windows - Builds my game for Windows.
• Windows Steam - Deploys my game to Steam

The way this setup works is like this

• My default stream is main. If there is a new change to main, the deploy all command is ran and it deploys a new build of my game to steam. I use feature toggles which I will explain in a later post to turn off features that are not playtest ready
• For all other streams, the build all command is ran. This is just to give me piece of mind that my builds aren’t failing and my tests are passing
• The backup config is ran once a week to backup all new changes on any of my streams
• The fill ddc config is ran twice a week to make sure my ddc is always up to date