Skip to content

chore(chart): appVersion 0.2.5, chart 0.3.5 (elasticsql 0.20.4 train) - #20

Merged
fupelaqu merged 1 commit into
mainfrom
chore/appversion-0.2.5
Aug 13, 2026
Merged

chore(chart): appVersion 0.2.5, chart 0.3.5 (elasticsql 0.20.4 train)#20
fupelaqu merged 1 commit into
mainfrom
chore/appversion-0.2.5

Conversation

@fupelaqu

@fupelaqu fupelaqu commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

Last of the six-repo train: core 0.20.4extensions 0.2.4arrow 0.2.5jdbc 0.2.5repl 0.20.4this.

from to
Chart.yaml version 0.3.4 0.3.5
Chart.yaml appVersion 0.2.4 0.2.5
federation-helm.yml IMAGE_TAG 0.2.3 0.2.5

What the images inherit

elasticsql 0.20.4 the completeness family — GROUP BY (#205), window PARTITION BY (#207), un-LIMITed SELECT (#209) and an explicit LIMIT above index.max_result_window (#224) no longer truncate silently; PIT paging sorts by _doc and gates at 7.12 (#197); the whole statement must parse (#213)
extensions 0.2.4 materialized-view error integrity — a cluster outage is no longer reported as 404 "does not exist" (#45), and a metadata table that cannot be created is no longer a 402 quota breach (#46)
arrow 0.2.5 the JOIN ceilings that killed the sidecar rather than degrading: legs past exactly 4,032 rows (#143), lazily streamed bounded legs (#147), a writable and bounded DuckDB spill directory (#141), a real health probe that sees allocator degradation (#146), and a default logback.xml so the images stop booting at ROOT DEBUG (#138 — a data-exposure fix as much as a performance one)

⚠️ Also reconciles the third surface

.github/workflows/federation-helm.yml IMAGE_TAG was still '0.2.3' — the 0.3.4 hop bumped the chart and left the workflow behind, exactly the drift the 0.2.3 hop had just fixed. The live-install jobs docker pull and kind load that tag independently of the chart, so CI was loading 0.2.3 images while the goldens rendered 0.2.4. Its own comment says MUST match Chart.yaml appVersion.

Goldens

All seven regenerated. Checked for pre-existing drift first (none — all seven rendered byte-identical before the bump), so the diff is only what appVersion drives: image tags, helm.sh/chart, app.kubernetes.io/version, and the ConfigMap checksums that follow from them.

✅ Image gate — cleared

appVersion is the default image tag, so this chart is only mergeable once the images exist. Re-probed at push time, all five answer HTTP 200 on DockerHub:

softnetwork/softclient4es-federation:0.2.5
softnetwork/softclient4es{6,7,8,9}-arrow-flight-sql:0.2.5

(They were 404 when the commit was authored — the commit message records that state and is now superseded.)

Verified locally — the full static gate

  • helm lint clean on the chart and all three examples
  • kubeconform -strict clean on base + three examples (3 / 7 / 11 / 11 resources, 0 invalid)
  • all seven goldens re-render byte-identical
  • zero kind: Secret
  • A2b discriminator holds: 3 commented duckdb-attach previews in heterogeneous-ready, 0 in three-region, and the two example goldens stay byte-identical to each other

🤖 Generated with Claude Code

Last of the six-repo train: core 0.20.4 -> extensions 0.2.4 ->
arrow 0.2.5 -> jdbc 0.2.5 -> repl 0.20.4 -> THIS.

The chart deploys the federation server and its per-ES-version sidecars,
so it inherits the whole 0.20.4 train through the images:

  elasticsql 0.20.4   the completeness family — GROUP BY (#205), window
                      PARTITION BY (#207), un-LIMITed SELECT (#209) and
                      an explicit LIMIT above index.max_result_window
                      (#224) no longer truncate silently; PIT paging
                      sorts by _doc and gates at 7.12 (#197); the WHOLE
                      statement must parse (#213)
  extensions 0.2.4    materialized-view error integrity — a cluster
                      outage is no longer reported as 404 "does not
                      exist" (#45), and a metadata table that cannot be
                      created is no longer a 402 quota breach (#46)
  arrow 0.2.5         the JOIN ceilings that killed the sidecar rather
                      than degrading: legs past exactly 4,032 rows
                      (#143), lazily streamed bounded legs (#147), a
                      writable and BOUNDED DuckDB spill directory
                      (#141), a real health probe that sees allocator
                      degradation (#146), and a default logback.xml so
                      the images stop booting at ROOT DEBUG (#138 — a
                      data-exposure fix as much as a performance one)

ALSO RECONCILES THE THIRD SURFACE: .github/workflows/federation-helm.yml
IMAGE_TAG was still '0.2.3' — the 0.3.4 hop bumped the chart and left the
workflow behind, exactly the drift the 0.2.3 hop had just fixed. The live
jobs pull and kind-load that tag independently of the chart, so CI was
loading 0.2.3 images while the goldens rendered 0.2.4. Now '0.2.5'.

All seven goldens regenerated. Checked for pre-existing drift FIRST (none
— all seven rendered byte-identical before the bump), so the diff is only
what appVersion drives: image tags, `helm.sh/chart`,
`app.kubernetes.io/version`, and the ConfigMap checksums that follow.

🔴 DO NOT MERGE UNTIL THE IMAGES EXIST. Probed at authoring time, all five
tags answer 404 on DockerHub:
  softnetwork/softclient4es-federation:0.2.5
  softnetwork/softclient4es{6,7,8,9}-arrow-flight-sql:0.2.5
appVersion is the DEFAULT image tag, so merging early ships a chart whose
pods cannot pull. Re-probe all five after the arrow 0.2.5 images are built.

Verified locally, the full static gate: helm lint clean on the chart and
all three examples; kubeconform -strict clean on base + three examples
(3/7/11/11 resources, 0 invalid); all seven goldens re-render
byte-identical; zero kind:Secret; the A2b discriminator holds (3 commented
duckdb-attach previews in heterogeneous-ready, 0 in three-region) and the
two example goldens stay byte-identical to each other.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@fupelaqu
fupelaqu merged commit 61d9e9f into main Aug 13, 2026
15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant