Antalya-26.8 - Port CI fixes from Antalya-26.6 (#2261, #2255, #2327)

[CarlosFelipeOR]

Ports three CI fixes from antalya-26.6 that still apply to 26.8:

• Antalya-26.6 - Fix test_s3_cluster startup failure under db disk (duplicate shard/replica macros) #2261: unique shard/replica macros in test_s3_cluster. The db disk lane fails at startup (4/36 jobs on 26.8).
• Antalya-26.6 - Fix races in the export_merge_tree_part test family #2255: wait for export completion instead of fixed sleeps in the export_merge_tree_part tests.
• Add dedicated cas suite to regression and split lightweight_delete CAS jobs #2327: dedicated cas regression suite and lightweight_delete/attach splits. The single lightweight_delete job hits the ~210 min timeout on 26.8.

Changelog category (leave one):

• CI Fix or Improvement (changelog entry is not required)

CI/CD Options

Exclude tests:

• Fast test
• Integration Tests
• Stateless tests
• Stateful tests
• Unit tests
• Performance tests
• Aarch64 tests
• All with ASAN
• All with TSAN
• All with MSAN
• All with UBSAN
• All with Coverage
• All Regression
• Disable CI Cache

Regression jobs to run:

• Fast suites (mostly <1h)
• Aggregate Functions (2h)
• Alter (1.5h)
• Benchmark (30m)
• CAS (content-addressed storage; Antalya only)
• ClickHouse Keeper (1h)
• Iceberg (2h)
• LDAP (1h)
• OAuth (5m)
• Parquet (1.5h)
• RBAC (1.5h)
• SSL Server (1h)
• S3 (2h)
• S3 Export (2h)
• Swarms (30m)
• Tiered Storage (2h)

[github-actions]

Workflow [PR], commit [99e1347]

[zvonand]

@blau-ai resolve conflicts directly in current branch

[blau-ai]

I looked at the merge conflict between ci/antalya-26.8/port-26.6-ci-fixes (3b504671ed5) and the current antalya-26.8 (25d9892715f). Here's the full picture and the exact resolution — but I hit a wall actually pushing it, explained at the bottom.

There is only one real conflict

Of the 8 files this PR touches, only two were also changed on antalya-26.8 since the merge-base (bd4bd7ba31b):

File	Base side	PR side	Result
tests/queries/0_stateless/03604_export_merge_tree_partition.sh	deleted	modified (sleep → wait_for_partition_exports)	conflict (modify/delete)
tests/integration/test_s3_cluster/test.py	adds test_global_join_executes_on_shards at ~L1426	adds replica2_c2 macro at ~L163	auto-merges (non-overlapping)

Everything else in the PR — export_part.lib, 03572_*, 03608_*, and the two regression*.yml files — is untouched on base and applies cleanly.

Why 03604 conflicts, and the correct resolution

On antalya-26.8, commit aaf00db0116 ("Port plain MergeTree partition exports onto antalya-26.8") reworked the whole export-partition feature and deleted 03604_export_merge_tree_partition.sh + its .reference, replacing them with the new stateless tests 05027_export_partition_merge_tree.sh and 05028_export_partition_replicated_merge_tree.sh (plus export_partition.lib). The PR's change to 03604 (swapping the sleeps for wait_for_partition_exports) is therefore obsolete — base already covers that scenario with the new tests.

So the right resolution is to accept base's deletion of 03604:

git checkout ci/antalya-26.8/port-26.6-ci-fixes
git fetch origin antalya-26.8
git merge origin/antalya-26.8
# -> CONFLICT (modify/delete): 03604_export_merge_tree_partition.sh deleted on base
git rm tests/queries/0_stateless/03604_export_merge_tree_partition.sh
git commit --no-edit        # test.py auto-merges; the .reference is auto-removed
git push

Notes:

• 03604_export_merge_tree_partition.reference is deleted on base and untouched by the PR, so it is removed automatically — no manual action needed.
• Keeping the PR's 03604 instead would just resurrect a duplicate of base's 05028, so deletion is the correct choice. (system.replicated_partition_exports still resolves on base — it's kept as a backwards-compat alias of the new system.partition_exports — so export_part.lib's wait_for_partition_exports helper is unaffected; it simply has no remaining caller after 03604 is dropped.)

Why I couldn't push this myself

You asked me to resolve it directly in the branch, and the push policy allows that here — but my sandbox blocks every operation this particular resolution needs: rm is denied for any file (even ones I create), and git merge / git rm / git restore / git update-index are all gated behind an approval I can't grant. git add and git commit work, but with no way to stage a file deletion I can't produce the resolving commit. The fix is the four commands above and is completely mechanical; please run them (or re-run me in a less restricted mode) and CI will validate.

[zvonand]

@blau-ai

[blau-ai]

CI triage for #2556

Verdict: the red checks fall into 4 groups — 1 PR-fixable (DCO), 1 flaky/infra, 1 environmental blocker (CAS), 1 pre-existing (settings). None of them is a bug in the three ports themselves (test_s3_cluster macros, export-test waits, regression YAML splits); the test-content changes look fine. Details below.

---

1. DCO — ❌ PR-related, you can fix it

Three commits on the branch have no Signed-off-by trailer:

commit	author
99e1347	Andrey Zvonov (the conflict-resolution commit)
3b50467	strtgbb
0ecd126	CarlosFelipeOR (has Co-Authored-By but no Signed-off-by)

Fix: re-sign the branch and force-update your own PR head, e.g.
git rebase --signoff antalya-26.8 && git push --force-with-lease.
(I can't do this myself — it needs a history rewrite + force-push, which is outside my permissions.)

---

2. Integration tests (amd_asan_ubsan, db disk, old analyzer, 3/8) — ⚠️ flaky / infra, not PR-caused

This is an ERROR, not a test failure — it blew up during setup, before any test ran, at clickhouse --version:

Decompressing the binary/ClickHouse/utils/self-extracting-executable/decompressor.cpp:209:60:
runtime error: pointer index expression with base 0x7b... overflowed to 0xbd...
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior .../decompressor.cpp:209:60

The same binary ran fine in the other db-disk lanes (2/8 and 4/8–8/8 are OK, 1/8 still running), so this is a transient UBSan hiccup in the self-extracting decompressor, not something this PR touched (your change is to test_s3_cluster/test.py, which never got to run here). Safe to re-run.

---

3. All Regression release cas_* / RegressionTestsRelease / CAS* suites — 🚧 environmental blocker (the port works, the branch isn't ready)

Every CAS suite fails identically at server startup:

ClickHouse server is not healthy
Code: 137. DB::Exception: MetadataStorageFactory: unknown metadata storage type: cas.
  (UNKNOWN_ELEMENT_IN_CONFIG)

I checked the tree at this SHA — src/Disks/DiskObjectStorage/MetadataStorages/MetadataStorageFactory.cpp registers only local, keeper, plain, plain_rewritable, web, web_index. There is no cas metadata type in antalya-26.8 — content-addressed storage simply hasn't been ported to this branch yet.

The #2327 port adds the new CASSuite/CASS3CacheSuite jobs and gates them on contains(version.string, 'antalya'). That gate is true on antalya-26.8, so the jobs schedule and run — but the build has no CAS feature, so they can't pass. The suite definitions are correct; the branch just lacks the feature they exercise.

Fix options:

• Easiest for this PR: don't enable the CAS regression on 26.8 — untick ci_regression_cas (and drop/skip the tiered_storage_cas run) so the port lands without red CAS checks. The job definitions stay in the YAML for when CAS arrives.
• Or gate CAS on the feature actually being present rather than just the antalya substring, since >= 26.6 is no longer a reliable proxy (26.6 had CAS, 26.8 doesn't).
• The CAS checks will only go green once the CAS storage feature itself is ported onto antalya-26.8.

---

4. Regression release settings (Common / settings) — ⬜ pre-existing drift, not PR-caused

The settings → default values suite fails with AssertionError across essentially every setting (incl. all the new upstream ai_function_* ones). This is the well-known testflows "default values" reference-drift check — it compares the server's current settings/defaults against a committed reference that lags upstream. This PR doesn't touch any setting or default, so it isn't the cause; it fails the same way on the base branch. Needs a separate reference refresh, out of scope here.

---

TL;DR for getting this PR green: (1) git rebase --signoff + force-push to clear DCO; (2) re-run the db-disk integration lane (flaky); (3) drop CAS regression from this PR until CAS is ported to 26.8 — those failures are the branch missing the feature, not the port being wrong; (4) the settings regression is pre-existing and unrelated.