hack/runner-release-watch.sh builds every key set with kube_keys, whose END block seeds the traversal queue with for (x in seen) if (x ~ /^Kubernetes/) and then follows field type references from there. So every comparison in the generated issue covers the Kubernetes executor subtree and nothing else.
The prose line is honest about this: "Upstream executor toml keys, vX to vY". Four section headings are not, and they are what a reader actually acts on:
### No keys added upstream followed by "No new CRD fields needed for the executor config."### Added upstream, so likely new CRD fields### Every upstream key is exposed### Removed upstream, so possibly dead here
Each reads as a statement about the release. None can be.
It has already produced a wrong answer
#61 (v19.1.0 to v19.2.2) printed "No keys added upstream". Diffing every toml: key in upstream common/config.go across those tags gives 408 against 424: 16 new key names, 23 (struct, key) pairs, zero removed. They sit under [[runners]].experimental.boot_verify (enabled, timeout, acquire_min_backoff, acquire_max_backoff) and [global].experimental.usage_logger (writers, logrotate.*, snowplow_billing.*). The [[runners]] ones are in the section internal/generate/config.go renders, so "no new CRD fields needed" was a judgement nobody actually made; it was inherited from a comparison that could not see the keys.
None of them needed exposing, as it happens: all opt-in, none changing a default. The defect is that the issue asserted it rather than surfacing it for a decision.
#74 (v19.2.2 to v19.3.0) says the same thing and is correct, but only coincidentally: that pair genuinely added and removed nothing in any section, 424 keys both sides. A heading that is right by luck is not a check.
Suggested fix
Cheapest and in keeping with what #70 already did for the flat-name problem: say what was compared in the headings, not just in the prose. "No keys added to the Kubernetes executor config", "Every upstream executor key is exposed", and so on. That costs four string edits and removes the over-claim.
If a wider check is wanted, extract all toml: keys rather than only the Kubernetes* closure and report the non-executor delta as its own section, so experimental.* growth becomes visible instead of silent. That is more useful and noisier; the honest headings are worth doing either way.
Found while closing #61.
hack/runner-release-watch.shbuilds every key set withkube_keys, whoseENDblock seeds the traversal queue withfor (x in seen) if (x ~ /^Kubernetes/)and then follows field type references from there. So every comparison in the generated issue covers the Kubernetes executor subtree and nothing else.The prose line is honest about this: "Upstream executor toml keys, vX to vY". Four section headings are not, and they are what a reader actually acts on:
### No keys added upstreamfollowed by "No new CRD fields needed for the executor config."### Added upstream, so likely new CRD fields### Every upstream key is exposed### Removed upstream, so possibly dead hereEach reads as a statement about the release. None can be.
It has already produced a wrong answer
#61 (v19.1.0 to v19.2.2) printed "No keys added upstream". Diffing every
toml:key in upstreamcommon/config.goacross those tags gives 408 against 424: 16 new key names, 23 (struct, key) pairs, zero removed. They sit under[[runners]].experimental.boot_verify(enabled,timeout,acquire_min_backoff,acquire_max_backoff) and[global].experimental.usage_logger(writers,logrotate.*,snowplow_billing.*). The[[runners]]ones are in the sectioninternal/generate/config.gorenders, so "no new CRD fields needed" was a judgement nobody actually made; it was inherited from a comparison that could not see the keys.None of them needed exposing, as it happens: all opt-in, none changing a default. The defect is that the issue asserted it rather than surfacing it for a decision.
#74 (v19.2.2 to v19.3.0) says the same thing and is correct, but only coincidentally: that pair genuinely added and removed nothing in any section, 424 keys both sides. A heading that is right by luck is not a check.
Suggested fix
Cheapest and in keeping with what #70 already did for the flat-name problem: say what was compared in the headings, not just in the prose. "No keys added to the Kubernetes executor config", "Every upstream executor key is exposed", and so on. That costs four string edits and removes the over-claim.
If a wider check is wanted, extract all
toml:keys rather than only theKubernetes*closure and report the non-executor delta as its own section, soexperimental.*growth becomes visible instead of silent. That is more useful and noisier; the honest headings are worth doing either way.Found while closing #61.