• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

kubeflow / trainer / 36777559515
72%

Build:
DEFAULT BRANCH: master
Ran 30 Sep 2026 09:14PM UTC
Jobs 1
Files 44
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

30 Sep 2026 09:09PM UTC coverage: 70.547% (+0.8%) from 69.787%
36777559515

push

github

web-flow
fix(controller): stop TrainJob reconcile panicking on an unsupported runtimeRef (#4088)

* fix(controller): stop TrainJob reconcile panicking on an unsupported runtimeRef

Reconcile treats an unresolvable spec.runtimeRef as a reportable state and sets
a Failed condition with TrainJobRuntimeNotSupportedReason, then passes the
runtime it did not find to setTrainJobStatus, which calls TrainJobStatus on a
nil interface.

r.runtimes is a map of interface values, so a lookup miss leaves the runtime
nil. controller-runtime recovers the panic and requeues, so the manager stays
up, but the unwind happens before the status patch: the condition never reaches
the API server and every retry panics at the same point, leaving the TrainJob
with nothing that explains why it never starts.

Deriving the status only when a runtime was found leaves the rest of the path
untouched, so the condition now survives to the patch.

Admission normally rejects an unsupported runtimeRef, which is why this has
gone unnoticed, but webhook.failurePolicy is a documented Helm value and a
TrainJob can be admitted under Ignore while the webhook is unavailable.

Signed-off-by: Abhishek <abhikokadwar2@gmail.com>

* fix(controller): derive TrainJob status inside the supported-runtime branch

Address review feedback: setTrainJobStatus now runs in the branch where the
runtime was found, straight after reconcileObjects, instead of behind a
separate check on ok. The unsupported runtime path can no longer reach it, so
the guard and its comment go away.

It stays outside the IsTrainJobFinished check, so finished TrainJobs still have
their status refreshed as before. Running it before setSuspendedCondition does
not change the result: the JobSet status plugin starts from a copy of the
existing status and never touches the Suspended condition, and
setSuspendedCondition only reads spec.suspend and that condition.

Signed-off-by: Abhishek <abhikokadwar2@gmail.com>

---------

Signed-off-by: Abhishek <ab... (continued)

1 of 15 new or added lines in 1 file covered. (6.67%)

4 existing lines in 2 files now uncovered.

2812 of 3986 relevant lines covered (70.55%)

0.82 hits per line

Uncovered Changes

Lines Coverage ∆ File
14
41.76
18.55% pkg/controller/trainjob_controller.go

Coverage Regressions

Lines Coverage ∆ File
3
74.07
-11.11% pkg/runtime/core/core.go
1
41.76
18.55% pkg/controller/trainjob_controller.go
Jobs
ID Job ID Ran Files Coverage
1 36777559515.1 30 Sep 2026 09:14PM UTC 44
70.55
GitHub Action Run
Source Files on build 36777559515
  • Tree
  • List 44
  • Changed 2
  • Source Changed 0
  • Coverage Changed 2
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • 78abeb24 on github
  • Prev Build on master (#36759842357)
  • Next Build on master (#36786581710)
  • Delete
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc