PR Checks / hadolint (pull_request) Successful in 23s
Docker Build and Push / test (pull_request) Successful in 5m19s
PR Checks / build-test (pull_request) Successful in 47s
Docker Build and Push / integration-test (pull_request) Successful in 5m30s
PR Checks / pytest (pull_request) Successful in 3m7s
Docker Build and Push / build (pull_request) Successful in 3m14s
The integration test job has been failing intermittently on main and on open pull requests with `httpx.ReadTimeout: timed out` on the first write to Qdrant, while `GET /collections` and `/healthz` kept answering. Cause: the qdrant-client default request timeout is 5 seconds, and the job only waits for `/healthz`, which is served before the storage engine accepts writes. On a shared runner doing several builds at once, the first collection creation or indexing exceeds 5s and the whole fixture errors out. - pin qdrant/qdrant to v1.19 (the digest `latest` and the cluster already run) and let Renovate track the pin in the workflows as well - wait for a real write round-trip (create + delete a probe collection) instead of `/healthz` alone, and dump the container logs if it never becomes writable - make the Qdrant client timeout configurable via QDRANT_TIMEOUT and set it to 60s in CI, where there is no latency SLA
17 lines
555 B
JSON
17 lines
555 B
JSON
{
|
|
"$schema": "https://docs.renovatebot.com/renovate-schema.json",
|
|
"customManagers": [
|
|
{
|
|
"customType": "regex",
|
|
"description": "Track the pinned qdrant/qdrant image in docker-compose.yml and the CI workflows (native manager missed it)",
|
|
"managerFilePatterns": [
|
|
"/^docker-compose\\.ya?ml$/",
|
|
"/^\\.gitea/workflows/.*\\.ya?ml$/"
|
|
],
|
|
"matchStrings": ["(?:docker\\.io/)?qdrant/qdrant:(?<currentValue>[^\\s\"']+)"],
|
|
"depNameTemplate": "qdrant/qdrant",
|
|
"datasourceTemplate": "docker"
|
|
}
|
|
]
|
|
}
|