The coverage gate cannot be reproduced locally (Go 1.26 counts 404 blocks where CI's 1.27 counts 414) and has no rounding headroom left #704

Activity

1. tannevaled commented on Oct 12, 2026

   

   tannevaled

   on Oct 12, 2026

   Last edited by tannevaled

   ContributorAuthor

   More actions

   Both halves are resolved — measured on main today

   1. The toolchain divergence is closed by construction

   The suggested fix was "pin the toolchain in the workflow (go-version: '1.27.1'
   rather than stable) and document that local runs must use the same one". The
   pin landed (#808 moved it to 1.27.2, in all four places), and the second half
   turns out to need no documentation — it is automatic:

   $ grep -c "go-version: 1.27.2" .github/workflows/ci.yml
   4
   $ grep '^go ' go.mod
   go 1.27.2
   $ go env GOTOOLCHAIN
   auto
   $ go version
   go version go1.27.2 darwin/arm64

   GOTOOLCHAIN=auto makes a local go follow the go directive, so any
   developer whose Go is new enough runs exactly 1.27.2 — the version CI pins —
   without being told to. And actions/setup-go sets GOTOOLCHAIN=local when
   given an explicit version, so CI cannot silently fetch a different one either.
   Both sides land on the same toolchain, which is what the issue asked for.

   That mechanism has a sharp edge worth recording while it is in view: on this
   machine the binary at …/v1.27.1/bin/go reports go1.27.2, because auto
   downloaded and ran what the directive asked for. The path names a version; it
   does not run one. go version is the only way to find out, and it is why the
   GOTOOLCHAIN=local pin in CI is load-bearing rather than decorative — it is
   exactly what made #792's nine red lanes say
   go: go.mod requires go >= 1.27.2 (running go 1.27.1; GOTOOLCHAIN=local)
   instead of quietly measuring something else.

   2. The rounded total is gone — the gate compares the list

   This issue's preferred option was "make the gate compare the below-100 list
   against main's rather than a rounded total, which is what every contributor is
   already told to do by hand". That is what cmd/covratchet +
   scripts/coverage/BELOW100.<lane> do:

   functions below 100%: 40 measured, 40 recorded
   coverage ratchet OK -- no function newly below 100%
   

   and when something regresses it names it rather than tipping a percentage:

   -- NEWLY BELOW 100% (1) --
      internal/vm/builtins.go explicitlyFrozen  90.0% (was fully covered)
   

   That one is from this week, and it is the mechanism working: a 90% function in a
   67-entry list could not have moved a rounded total at all.

   3. The three functions this issue named are now covered

   bigdecimal_bind.go Inspect, date_bind.go Inspect and date_bind.go ToS were
   all at 0.0%, recorded in both lanes. #815 covers them, and they did not have
   the same answer:

   • Two were untested. One line of Ruby reaches each, and the output already
     matched MRI 4.0.7.
   • One was neither. (*Date).ToS was unreachable from Ruby, because to_s
     was registered separately as strM((*date.Date).String) — and it cannot be
     deleted, since object.Value requires ToS. So the method existed to satisfy
     an interface while a second path did the work, and the two renderings of a
     Date could drift with nothing able to notice. to_s now goes through it.

   Closing this on the strength of parts 1 and 2; the 0.0% entries are the last
   concrete item and are in flight.

   🤖 Generated with Claude Code