ForgeFX Build Intelligence · TeamCity + ForgeBuild

John Deere build analysis: last 30 days

The core production builds are healthy. The problem is not build delivery; it is a persistently failing unit-test lane that creates noise, burns roughly an hour per attempt, and hides useful signal.

222
TeamCity builds sampled
72.5%
overall finished-build success rate
61
failures, mostly one lane
0
ForgeBuild broken apps right now

Executive read

Shipping lanes are clean.

John Deere Quest builds, Pico builds, Windows builds, ForgeFX build scripts, and JDMini builds all reported 100% success in the sampled window.

Unit tests are the fire.

QuestUnitTests_JohnDeereUnitTests failed 58 of 59 runs. That single lane accounts for about 95% of all TeamCity failures.

Queueing is not the bottleneck.

Median queue time was 0 minutes; p90 queue was 14.5 minutes. The pain is runtime and test failure, not capacity starvation.

Recommended fix order

  1. Quarantine or fix the repeating John Deere unit-test cluster first. Recent Slack/TeamCity notifications point to lesson-load simulator tests, HapticUIButton.OnEnable, and destroyed UnityEngine.Canvas access during teardown/state transitions.
  2. Keep Quest/Pico/Windows build lanes as release confidence lanes. They are green; do not block them behind a noisy unit-test lane unless the failing tests are release-critical.
  3. Tighten ForgeBuild's Vercel signal. Live sites and DNS are broadly fine, but many apps show unknown/no-recent-deploy Vercel metadata, so ForgeBuild is useful for live drift but less useful as a clean green-board until Vercel project mapping/metadata is completed.

TeamCity patterns

Daily volume and failures

06-02
4 / 1
06-03
10 / 3
06-04
7 / 1
06-05
5 / 1
06-06
1 / 0
06-07
1 / 0
06-08
11 / 3
06-09
14 / 4
06-10
8 / 2
06-11
13 / 5
06-12
11 / 3
06-13
1 / 0
06-14
1 / 0
06-15
10 / 2
06-16
10 / 4
06-17
7 / 2
06-18
13 / 4
06-19
4 / 1
06-20
5 / 2
06-21
1 / 0
06-22
8 / 2
06-23
15 / 4
06-24
6 / 1
06-25
11 / 3
06-26
4 / 1
06-27
3 / 1
06-28
1 / 0
06-29
18 / 5
06-30
15 / 5
07-01
4 / 1
Window
2026-06-01T17:07:30.674Z → 2026-07-01T17:07:30.674Z

Runtime
Median finished runtime: 43.3m
P90 finished runtime: 84.8m

Queue
Median queue: 0m
P90 queue: 14.5m

Build type health

Build typeTotalSuccessFailuresMedianP90Read
John Deere Version Updates
BuildTrigger_JohnDeereVersionUpdates
6198.4%11.5m2.3mNeeds attention
John Deere Unit Tests
QuestUnitTests_JohnDeereUnitTests
591.7%5868.3m86.6mNeeds attention
John Deere Builds
QuestBuilds_JohnDeereBuilds
55100%048.2m101.5mHealthy
Build Scripts
ForgeFX_BuildScripts
31100%00.9m0.9mHealthy
Pico John Deere Builds
QuestBuilds_PicoJohnDeereBuilds
11100%041m72mHealthy
John Deere Windows Builds
WindowsBuilds_JohnDeereWindowsBuilds
2100%046.8m47.5mHealthy
ForgeSim Unit tests
QuestUnitTests_ForgeSimUnitTests
20%210.5m12.1mNeeds attention
Jdmini Builds
Workbench_JdminiBuilds
1100%08m8mHealthy

Failure concentration

LaneFailure countRecent failure textLatest source
John Deere Unit Tests
QuestUnitTests_JohnDeereUnitTests
58Tests failed: 4, passed: 109, ignored: 4TeamCity #706
ForgeSim Unit tests
QuestUnitTests_ForgeSimUnitTests
2Tests failed: 5, passed: 10, ignored: 7TeamCity #172
John Deere Version Updates
BuildTrigger_JohnDeereVersionUpdates
1Build stopped: Updates were rejected because the remote contains work that you do not have locally. (new); exit code 1 (Step: GIT> Commit/Push === Version === (Command Line)) (new)TeamCity #687

ForgeBuild live deployment signal

ForgeBuild is a separate wallboard for the forgeapps monorepo. It does not replace John Deere Unity/TeamCity history, but it confirms whether ForgeFX web app deployment plumbing is currently broken or drifting.

52
ForgeBuild apps checked
52
live URLs OK
0
apps drifting behind latest app commit
1
fully green across all stages

Why only 1 fully green?

The strict green score requires GitHub, Vercel metadata, live URL, DNS, and drift all to be clean. The report found 0 broken apps and 0 drifting apps, but many apps lack recent/complete Vercel deploy metadata, so they are not counted as fully green even when their live sites return 200 and DNS resolves.

AppGitHubVercelLiveDNSDrift
adamkanecommittedno recent deploy200 OKresolvesunknown
adamobotcommittedunknown200 OKresolvesin sync
allycommittedno recent deploy200 OKresolvesunknown
aracommittedno recent deploy200 OKresolvesunknown
bofacommittedno recent deploy200 OKresolvesunknown
chetancommittedunknown200 OKresolvesin sync
deepwikicommittedno recent deploy200 OKresolvesunknown
dopplescommittedunknown200 OKresolvesin sync
examplecommittedunknown200 OKresolvesin sync
fitfindercommittedno recent deploy200 OKresolvesunknown
forgebasecommittedunknown200 OKresolvesin sync
forgeboardcommittedunknown200 OKresolvesin sync
forgebookscommittedunknown200 OKresolvesin sync
forgebotcommittedno recent deploy200 OKresolvesunknown
forgebriefcommittedno recent deploy200 OKresolvesunknown
forgebuildcommittedno recent deploy200 OKresolvesunknown

What I would do next

1. Attack the noisy test lane.

Pull the last 10 failing logs for QuestUnitTests_JohnDeereUnitTests, cluster stack traces, and assign one owner-ready bug around the destroyed Canvas / boot-screen transition failure.

2. Separate release gate from known-noisy checks.

Until the unit-test cluster is fixed, mark the known failure pattern separately so green Quest builds stay visible.

3. Improve ForgeBuild metadata coverage.

Finish Vercel project mapping for apps reporting unknown/no recent deploy so the wallboard becomes stricter and less ambiguous.