gbreed-public/gbr-games
5
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(ark): retry the install; ready when advertising for join #3

Merged
greg merged 3 commits from fix/ark-install-retry into main 2026-10-25 15:10:18 +00:00
Conversation 2 Commits 3 Files Changed 2
+5 -4
greg commented 2026-10-25 06:36:20 +00:00
Owner
Copy link
Copy source

Two ARK fixes found with the new first-boot tool.

1. Retry the server install

The image's start_server runs SteamCMD once and carries on even when it fails. SteamCMD's intermittent Missing configuration error then left no server installed, so ARK exited (code 1). On nodes, the restart policy hid this as a slow first start; a boot test would fail on the restart.

The startup command now downloads SteamCMD if needed, runs the standard +login anonymous +quit warm-up (the node-agent's own SteamCMD installs do the same), and installs app 2430930, retrying up to 3 times until ArkAscendedServer.exe exists. start_server's own install step then only validates.

2. Ready line

First boot with the fix, from ARK's ShooterGame.log:

06:30:00  Server: "ARK #529161" has successfully started!
06:30:00  EOS ownership validation initialized: Success
06:30:31  Full Startup: 36.26 seconds
06:32:24  Server has completed startup and is now advertising for join. (9.96GB Mem)

"Advertising for join" is when players can join, console players through EOS included, so it's the readyPattern. The real line is test.yaml's readyExample, which validation checks the pattern against. Boot tests now wait for it instead of only checking ARK stays up for 10 minutes.

ARK used ~10 GB at that point, so the template's 16 GB is right. A local run capped at 12 GB exited silently.

Tested

  • Validation and inspect-image pass.
  • First boot locally: install succeeded first try with the warm-up, server reached "advertising for join", stopped cleanly.
  • CI boot-tests ARK on this PR with the node-agent.

🤖 Generated with Claude Code

Two ARK fixes found with the new first-boot tool. ## 1. Retry the server install The image's `start_server` runs SteamCMD once and **carries on even when it fails**. SteamCMD's intermittent `Missing configuration` error then left no server installed, so ARK exited (code 1). On nodes, the restart policy hid this as a slow first start; a boot test would fail on the restart. The startup command now downloads SteamCMD if needed, runs the standard `+login anonymous +quit` warm-up (the node-agent's own SteamCMD installs do the same), and installs app 2430930, **retrying up to 3 times until `ArkAscendedServer.exe` exists**. `start_server`'s own install step then only validates. ## 2. Ready line First boot with the fix, from ARK's `ShooterGame.log`: ``` 06:30:00 Server: "ARK #529161" has successfully started! 06:30:00 EOS ownership validation initialized: Success 06:30:31 Full Startup: 36.26 seconds 06:32:24 Server has completed startup and is now advertising for join. (9.96GB Mem) ``` "Advertising for join" is when players can join, console players through EOS included, so it's the `readyPattern`. The real line is `test.yaml`'s `readyExample`, which validation checks the pattern against. Boot tests now wait for it instead of only checking ARK stays up for 10 minutes. ARK used ~10 GB at that point, so the template's 16 GB is right. A local run capped at 12 GB exited silently. ## Tested - Validation and `inspect-image` pass. - First boot locally: install succeeded first try with the warm-up, server reached "advertising for join", stopped cleanly. - CI boot-tests ARK on this PR with the node-agent. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
greg added 2 commits 2026-10-25 06:36:21 +00:00
fix(ark): retry the server install before handing over to the image 9fef27cd40 
The image's start_server runs SteamCMD once and carries on even when it
fails; SteamCMD's intermittent "Missing configuration" error then left
no server installed, so ARK exited and only the node's restart policy
saved it (a boot test would fail on the restart). First boot showed it.

The startup command now downloads SteamCMD if missing, runs the usual
"+login anonymous +quit" warm-up and installs app 2430930, retrying up
to three times until ArkAscendedServer.exe exists. start_server's own
install step then only validates.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
feat(ark): ready when advertising for join
Validate game templates / validate (push) Successful in 9m31s
Details
Validate game templates / boot-test (push) Successful in 15m9s
Details
Validate game templates / publish (push) Skipped
Details
65cbb8cfd4 
First boot with the install fix ran ARK for ~10 minutes and found, in
ShooterGame.log: "Server: ... has successfully started!", "EOS ownership
validation initialized: Success", "Full Startup: 36.26 seconds" and,
about two minutes later, "Server has completed startup and is now
advertising for join. (9.96GB Mem)". That last line is when players,
console players through EOS included, can join, so it is the
readyPattern; the real line is test.yaml's readyExample. Boot tests now
wait for it instead of only checking ARK stays up for 10 minutes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
git_ai_bot commented 2026-10-25 06:36:40 +00:00
Member
Copy link
Copy source

Automated AI Review

Here's some quick feedback on your PR:

  • If all three steamcmd install retries fail, the subshell exits with status 0 (last command is sleep 15), so the && chain proceeds to exec /usr/bin/start_server with the binary missing; a || exit 1 (or equivalent) after the done keyword would make the failure explicit.
  • The downloaded steamcmd_linux.tar.gz is piped straight into tar xz with no SHA-256 checksum verification, leaving the container vulnerable to a MITM-supplied binary.
  • The readyPattern line (Server has completed startup and is now advertising for join) is a plain substring with no anchoring or log-level prefix, so a future log line that merely contains that phrase (e.g., an error echoing it) would falsely mark the server as ready.
>_Automated AI Review_ Here's some quick feedback on your PR: - If all three steamcmd install retries fail, the subshell exits with status 0 (last command is `sleep 15`), so the `&&` chain proceeds to `exec /usr/bin/start_server` with the binary missing; a `|| exit 1` (or equivalent) after the `done` keyword would make the failure explicit. - The downloaded `steamcmd_linux.tar.gz` is piped straight into `tar xz` with no SHA-256 checksum verification, leaving the container vulnerable to a MITM-supplied binary. - The `readyPattern` line (`Server has completed startup and is now advertising for join`) is a plain substring with no anchoring or log-level prefix, so a future log line that merely contains that phrase (e.g., an error echoing it) would falsely mark the server as ready.
greg added 1 commit 2026-10-25 07:09:35 +00:00
Merge branch 'main' into fix/ark-install-retry
Validate game templates / validate (push) Successful in 9m33s
Details
Validate game templates / boot-test (push) Successful in 15m20s
Details
Validate game templates / publish (push) Skipped
Details
ba09fe35d7
greg merged commit c23442e8fa into main 2026-10-25 15:10:18 +00:00
greg deleted branch fix/ark-install-retry 2026-10-25 15:10:18 +00:00
git_ai_bot commented 2026-10-25 15:10:45 +00:00
Member
Copy link
Copy source

Automated AI Review

Here's some quick feedback on your PR:

  • After all three retry attempts fail the loop simply falls through to exec /usr/bin/start_server, which will fail with a cryptic error since the server binary was never installed; an explicit exit 1 (or echo + exit) after the for loop is needed.
  • The two steamcmd.sh invocations (+login and +app_update) have no error-code checks, so a persistent non-network failure (e.g. corrupt tarball, missing disk space) will be retried identically three times and only surface as a missing-file check at the end.
  • Removing settleSec in favour of readyPattern changes the readiness contract for the CI harness; confirm the test runner actually supports a per-game readyPattern field, otherwise the boot-test will only ever time out at timeoutSec: 2400.
>_Automated AI Review_ Here's some quick feedback on your PR: - After all three retry attempts fail the loop simply falls through to `exec /usr/bin/start_server`, which will fail with a cryptic error since the server binary was never installed; an explicit `exit 1` (or `echo` + `exit`) after the `for` loop is needed. - The two `steamcmd.sh` invocations (`+login` and `+app_update`) have no error-code checks, so a persistent non-network failure (e.g. corrupt tarball, missing disk space) will be retried identically three times and only surface as a missing-file check at the end. - Removing `settleSec` in favour of `readyPattern` changes the readiness contract for the CI harness; confirm the test runner actually supports a per-game `readyPattern` field, otherwise the boot-test will only ever time out at `timeoutSec: 2400`.
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
gbr-bot git_ai_bot git_pipeline greg (Gregory Reed) openhands
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: gbreed-public/gbr-games#3