Something went wrong. Try again.
Backend environment for match hosting for lance.blue
Something went wrong. Try again.
Shell
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283#!/usr/bin/env bash# The boot order is a performance guarantee, so it is asserted rather than left# to a comment. Two JVMs sit on the path between RunTask and a playable match,# and they only overlap if the host is launched before anything waits on# Suramadu's port. A refactor that puts the wait back in between costs every# match the host's whole startup, and nothing else in the suite would notice.## Structural assertions against the script text, in the style of# test-profiling.sh: the entrypoint cannot be run here - it launches JVMs and# reads /proc/net/tcp - but its ordering is a property of the file.set -uo pipefail
ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/../.." && pwd)"ENTRYPOINT="$ROOT/container/entrypoint.sh"
fail=0check() { # <description> <test-command...> if "${@:2}"; then echo "ok $1"; else echo "FAIL $1"; fail=1; fi}
# line <pattern> - the line number of the first match, or emptyline() { grep -n -- "$1" "$ENTRYPOINT" | head -1 | cut -d: -f1; }
WS_LAUNCH="$(line '^WS_PID=\$!')"HOST_LAUNCH="$(line '^HOST_PID=\$!')"WS_WAIT="$(line '^await_port Suramadu')"HOST_WAIT="$(line '^await_port "match host"')"READY="$(line '^emit ready')"# The launch, not the mention of it in the header comment.OBSERVER="$(line '^ *arena\.MatchWatcher --host')"# The host is told which fight it is playing, which is what puts the scenario in# the result. init/30-assets.sh writes both into run/scenario.env.SCENARIO_SOURCE="$(line '--scenario-source')"SCENARIO_LIBRARY="$(line '--scenario-library')"
for var in WS_LAUNCH HOST_LAUNCH WS_WAIT HOST_WAIT READY OBSERVER \ SCENARIO_SOURCE SCENARIO_LIBRARY; do check "$var was found in the entrypoint" test -n "${!var}"done[ "$fail" = 0 ] || { echo "cannot check ordering; the anchors moved"; exit 1; }
# The whole point: both JVMs are running before either is waited on.check "the host launches before the wait for Suramadu" \ test "$HOST_LAUNCH" -lt "$WS_WAIT"check "Suramadu launches before the host" \ test "$WS_LAUNCH" -lt "$HOST_LAUNCH"
# On the host's own command line, which is the whole path by which the scenario# reaches the result document: run/scenario.env -> the entrypoint -> MatchHost.between() { [ "$1" -gt "$2" ] && [ "$1" -lt "$3" ]; }check "the host is told which form the scenario came in" \ between "$SCENARIO_SOURCE" "$WS_LAUNCH" "$HOST_LAUNCH"check "and which library path it was picked from" \ between "$SCENARIO_LIBRARY" "$WS_LAUNCH" "$HOST_LAUNCH"
# Readiness means both ports, not just the web server's - headquarters sends a# browser the moment it hears `ready`.check "the ready callback follows the wait for Suramadu" \ test "$WS_WAIT" -lt "$READY"check "the ready callback follows the wait for the host" \ test "$HOST_WAIT" -lt "$READY"
# Third JVM. It must start beside the host, not after readiness: its cold start# is a full MegaMek client and after `ready` it lands on top of the player's own# client JVM spawning and the first board paint.check "the observer starts before readiness is announced" \ test "$OBSERVER" -lt "$READY"
# A startup failure has to take the other JVM down and tell headquarters, or the# waiting screen sits through the provisioning timeout for a task that is gone.check "startup_failed reports the failure to the control plane" \ grep -q 'emit error' "$ENTRYPOINT"check "startup_failed kills both JVMs" \ grep -qF 'for pid in "$HOST_PID" "$WS_PID"' "$ENTRYPOINT"
# The phase marks are what the whole change is for; losing them loses the# measurement.for p in init-done suramadu-launched host-launched suramadu-ready host-ready; do check "phase $p is stamped" grep -qF "phase $p" "$ENTRYPOINT"done
exit "$fail"