native-arch is green every night while both native lanes skip, and its s390x host address is dead #912

native-arch reports success every night while validating nothing, and its s390x target is an address that has been dead since 2026-10-09. The landing page cites this lane as evidence of native validation.

The lane is green and empty

$ gh run view 42476062143 --json jobs    # 2026-11-08, scheduled
success  check-secrets                                     steps=3
skipped  native ${{ matrix.arch }} (${{ matrix.host }})     steps=0
skipped  native s390x (linux1@148.100.85.193)              steps=0

Both native jobs skip — steps=0 — because check-secrets finds no CFARM_SSH_KEY / LINUX1_SSH_KEY and gates them off. Only the gate itself runs, and the run is success.

Five consecutive nights, same shape:

2026-11-08  schedule  success      2026-11-05  schedule  success
2026-11-07  schedule  success      2026-11-04  schedule  success
2026-11-06  schedule  success

⛔ A workflow that cannot distinguish "every architecture passed" from "nothing ran" reports the same green for both. The secrets gate is reasonable — a fork has no credentials — but the conclusion should not be success when every validating job was skipped.

And the s390x host address is dead

.github/workflows/native-arch.yml:

264:    name: native s390x (linux1@148.100.85.193)
269:      TARGET_HOST: 148.100.85.193
 46,49,60: the same address in the comments and the secret documentation

148.100.85.193 is the old z15. The host moved to linux1@148.100.85.168 (IBM z17, 8 vCPU) on 2026-10-09. So even with the secrets installed, the s390x lane would fail to connect — and because the lane is skipped, nothing has ever reported that.

The LINUX1_KNOWN_HOSTS documentation (:49) also names .193, so a ssh-keyscan done from it would key the wrong host.

Which makes a published claim unbacked

go-embedded-ruby.github.io states:

riscv64, loong64, ppc64le and s390x are validated on a nightly schedule — under qemu, and natively on the GCC Compile Farm plus an IBM LinuxONE s390x host — not on the pull-request path.

Neither half holds right now:

Witness that the native lane has not been running

I ran internal/vm on the real z17 by hand on 2026-11-07 (ssh linuxone, cross-compiled binary, 8 vCPU, load 0.00) and it was the first execution of that package on big-endian hardware — 7 of 9 initially-failing tests turned out to be missing repository files, not architecture. Figures and method are in #842. That is consistent with a lane that has never run, and inconsistent with nightly native validation.

What this needs, separately from fixing it

1. TARGET_HOST → 148.100.85.168, and the three comment references with it.
2. A conclusion that is not success when the validating jobs were all skipped — or, if a green fork run is wanted, something that makes the distinction legible (the check-secrets summary already prints which lanes are enabled; the run conclusion does not carry it).
3. The landing sentence to match whatever the lane actually does once it does it.

⛔ I am not changing the workflow here: items 1 and 2 are a CI decision (and 2 has a real trade-off for forks), and the secrets themselves are not something a session should touch. Filing with the measurement, which is the part that was missing.

🤖 Generated with Claude Code