[zvonand]

minio/minio was deleted from Docker Hub, so every with_minio=True test fails in cluster.start() on the image pull. Point docker_compose_minio.yml at the clickhouse/minio-minio mirror (upstream ClickHouse#119999). The mirror has no RELEASE.2023-09-30T07-02-29Z tag, so bump to RELEASE.2024-07-31T05-46-26Z, the same image releases/24.8.14 uses.

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)

[altinity-robot]

This is an automated comment for commit 922a4fc with description of existing statuses. It's updated for the latest CI running

✅ Click here to open a full report in a separate page

Successful checks

Check name	Description	Status
CI running	A meta-check that indicates the running CI. Normally, it's in success or pending state. The failed status indicates some problems with the PR	✅ success
ClickHouse build check	Builds ClickHouse in various configurations for use in further steps. You have to fix the builds that fail. Build logs often has enough information to fix the error, but you might have to reproduce the failure locally. The cmake options can be found in the build log, grepping for cmake. Use these options and follow the general build process	✅ success
Compatibility check	Checks that clickhouse binary runs on distributions with old libc versions. If it fails, ask a maintainer for help	✅ success
Docker keeper image	The check to build and optionally push the mentioned image to docker hub	✅ success
Docker server image	The check to build and optionally push the mentioned image to docker hub	✅ success
Grype Scan altinityinfra/clickhouse-keeper:2701-24.3.18.10327.altinitystable	There's no description for the check yet, please add it to tests/ci/ci_config.py:CHECK_DESCRIPTIONS	✅ success
Grype Scan altinityinfra/clickhouse-server:2701-24.3.18.10327.altinitystable-alpine	There's no description for the check yet, please add it to tests/ci/ci_config.py:CHECK_DESCRIPTIONS	✅ success
Grype Scan altinityinfra/clickhouse-server:2701-24.3.18.10327.altinitystable	There's no description for the check yet, please add it to tests/ci/ci_config.py:CHECK_DESCRIPTIONS	✅ success
Install packages	Checks that the built packages are installable in a clear environment	✅ success
Integration tests	The integration tests report. In parenthesis the package type is given, and in square brackets are the optional part/total tests	✅ success
Mergeable Check	Checks if all other necessary checks are successful	✅ success
Ready for release	There's no description for the check yet, please add it to tests/ci/ci_config.py:CHECK_DESCRIPTIONS	✅ success
Stateful tests	Runs stateful functional tests for ClickHouse binaries built in various configurations -- release, debug, with sanitizers, etc	✅ success
Stateless tests	Runs stateless functional tests for ClickHouse binaries built in various configurations -- release, debug, with sanitizers, etc	✅ success

[zvonand]

@blau-ai

[zvonand]

@blau-ai

[blau-ai]

CI triage for 922a4fc

4 failing checks: 0 caused by this PR, 4 from CI infrastructure (one root cause). Nothing in this PR needs fixing.

All build, stateless, stateful and integration jobs pass, including the with_minio=True integration tests this PR targets. The only red checks are the CVE scanners and the summary job that reads their output. The checks shown as skipped (Aarch64/TSAN/MSAN builds, Regression jobs) are the ones excluded in the PR description.

Check	Classification
GrypeScan (server) / Grype Scan	infra: outdated grype version
GrypeScan (server, -alpine) / Grype Scan	infra: same cause
GrypeScan (keeper) / Grype Scan	infra: same cause
FinishCheck	knock-on effect of the Grype failures

Grype Scan (all 3 jobs)

The ClickHouse images were pulled fine. Grype itself failed to load its vulnerability database (log):

WARN error updating db error=unable to activate new vulnerability database: failed to hydrate database: failed to open db: unable to migrate: constraint failed: UNIQUE constraint failed: operating_systems.name, ...
ERROR failed to load vulnerability db: database does not exist

The keeper and alpine jobs log the same two lines. releases/24.3.18 still pins GRYPE_VERSION: "v0.92.2-arm64v8" (.github/workflows/grype_scan.yml:23, .github/grype/run_grype_scan.sh:6), and that grype release can no longer read the current upstream DB schema. Other branches have already fixed this with 1ebf3b1 ("Fix Grype Scan: bump grype to v0.115.0 (v0.92.2 can't load current DB)"). Both antalya-26.3 and releases/24.8.14 now pin v0.115.0-arm64v8. This PR does not touch anything Grype-related, so the scan fails the same way for any run on this base branch.

FinishCheck

File ".github/create_workflow_report.py", line 445, in get_cves
    results.append(json.loads(content))
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

This happens because the Grype jobs uploaded empty result files. It will go green once Grype works.

Suggested next step (optional, not required for this PR)

To get Grype green on the 24.3 line, cherry-pick 1ebf3b1. It is a 2-line bump, v0.92.2 → v0.115.0, in .github/workflows/grype_scan.yml and .github/grype/run_grype_scan.sh. It could go on this PR or in a separate CI fix PR against releases/24.3.18. I have not pushed it, since you only asked for triage. Mention me if you want it on this branch. Otherwise, the functional checks for this MinIO-image change are fully green.

[zvonand]

Suggested next step (optional, not required for this PR)
To get Grype green on the 24.3 line, cherry-pick 1ebf3b1. It is a 2-line bump, v0.92.2 → v0.115.0, in .github/workflows/grype_scan.yml and .github/grype/run_grype_scan.sh. It could go on this PR or in a separate CI fix PR against releases/24.3.18. I have not pushed it, since you only asked for triage. Mention me if you want it on this branch. Otherwise, the functional checks for this MinIO-image change are fully green.

@blau-ai , do it in a separate PR into releases/24.3.18

[blau-ai]

@zvonand Done. I opened the Grype bump as a separate PR into releases/24.3.18: #2717

• Branch: blau/24.3.18-grype-bump, created from releases/24.3.18 at 74a8f2a1344
• Commit: 4c11259, a cherry-pick -x of 1ebf3b1. It applied cleanly with no conflicts.
• Change: Grype goes from v0.92.2 to v0.115.0 in .github/workflows/grype_scan.yml (v0.115.0-arm64v8) and in .github/grype/run_grype_scan.sh. That is the whole diff: 2 lines.

Nothing was pushed to this PR (#2701). The Grype checks on #2717 will show whether the bump fixes the scan; I have not run it locally.