Common Operations

Common Operations

There are a number of operations during a competition event which are frequently performed but worth understanding before they are needed.

Score entry

The score entry personnel will need a computer which is running the scorer. They need to be provided with completed score sheets from the linesmen as soon as reasonable after the end of matches.

Note: It is assumed that the linesmen complete paper score sheets, rather than directly interact with the scorer software, mostly as paper is a somewhat more reliable communication mechanism than WiFi.

Note: as the scorer needs customisation for each competition to ensure that it can save and load the data related to the game being played, it is typical to also change the visual appearance of the score input page such that it resembles the score sheets which are completed by the linesmen.

Score entry is performed in the web UI presented by the scorer by selecting the proper match, entering the details from the score sheet and saving them. This will then check that the scores are reasonable (e.g: contain the expected teams and the right number and combination of tokens) and commit the changes to the repository.

For important matches (such as those later in the competition, particularly in a knockout stage) it may be desirable to have a second person check that the input matches the score sheet.

Note: while the scorer can be run in a mode where it automatically pushes the new commit to the origin remote, this tends not to be used for a couple of reasons:

• pushing the changes doesn't deploy them
• not pushing allows input-checking can occur after commit and before push

Once the scores are committed, they can be deployed using srcomp deploy.

Client preparation

Various personnel may need to interact with a raw compstate during the course of a competition event. They will need to set up their local environment ahead of time to ensure that any actions they take can be performed efficiently in the moment.

The following steps are needed:

• Set up SRComp CLI locally.

  This can be installed with pipx install sr.comp.cli if you have pipx available, or as pip install sr.comp.cli if you're happy managing your own virtualenvs.

  Shell completions are available for bash, however setup of these is currently manual.

• Configure read/write access to the upstream compstate hosting.

• Configure read/write access to the various deployments for the compstate. If using SRComp puppet this is achieved by adding a suitable SSH public key to the modules/compbox/files/srcomp-authorized_keys file used in the configuration.

• Test the configuration by running srcomp fetch on the local compstate.

Deploying changes

Definition: A deployment is a host server on which the SRComp HTTP API is running and is accessible.

Anyone deploying changes needs to have the SRComp CLI set-up locally and have suitable access to the deployment hosts.

Deploying changes to a compstate is deliberately separated from pushing them from a shared repository. This is so that old versions can be deployed if necessary without needing to adjust history and so that there are no race conditions around deploying a change.

The locations of the deployments (i.e: hosts serving the HTTP API) of a compstate are stored within the compstate as a list of hostnames. The person performing the deploy must be able to SSH into each host as the user srcomp using key based authentication.

Changes are deployed by running the srcomp deploy command with the path to the compstate repo to deploy. The compstate must be checked out at the version to deploy and must not have any local changes.

As part of the process, the compstate is validated and the deployed versions are checked. Deployments which are already running the expected version are skipped and others are updated.

For events with more than one person deploying changes, the srcomp fetch command provides a way to fetch the latest changes from both a shared upstream and from all deployments.

Delaying matches

Anyone adding a delay needs to have the SRComp CLI set-up locally. If they are intending to deploy the delay they will also need to have suitable access to the deployment hosts.

Delays during the course of matches are likely and are explicitly supported by SRComp. Adding delays involves editing the compstate repo. While this can be done manually, this is discouraged in favour of using one of the commands provided.

A delay must be specified as a time at which the delay starts and a duration during which no match slots can start. (Note: matches whose slot has started will continue to run, even if the game itself has not started. This is considered a bug and may change.)

Adding a delay is done using the srcomp add-delay command which takes the path to a compstate repo, a duration and (optionally) a time.

For example, the following adds a 90 second delay starting from the current time:

$ srcomp add-delay ./compstate 1m30s

You can also add a delay to the current (in-progress) match slot using:

$ srcomp add-delay ./compstate 1m30s "current match"

The result is a modified compstate ready for the delay to be inspected and committed.

Delays in a hurry

Since most delays will need to be added at very short notice, it is typical to also want to deploy them immediately. To this end, a convenience wrapper exists which adds a delay, commits it and deploys the result:

$ srcomp delay ./compstate 90s

# roughly equivalent to:
$ (cd ./compstate \
    && srcomp add-delay . 90s \
    && srcomp validate . \
    && git commit schedule.yaml --message "Adding 90s delay at $(date)"
    && srcomp deploy .)