Conversation
Greptile SummaryThis PR upgrades the Gitpod integration stack from Appwrite 1.8.1 to 1.9.0, bumping all worker and scheduler images, the console image (7.5.7 → 7.8.26), Traefik (2.11 → 3.6), and Redis (7.2.4 → 7.4.7). It also improves startup reliability by adding health checks to MariaDB and Redis and converting all Key changes:
Critical issue found: Confidence Score: 3/5Not safe to merge without fixing the pervasive _APP_DB_ADAPTER duplication, which can prevent the stack from starting on strict Docker Compose versions. A P1 defect (duplicate environment variable key in every service's environment block) was introduced systematically across the entire file. While some Docker Compose versions may silently ignore duplicates, others will error at validation time and prevent the stack from starting entirely. docker-compose.yml — the duplicate _APP_DB_ADAPTER entries must be removed from all 18 service environment blocks before this is merged. Important Files Changed
Reviews (1): Last reviewed commit: "feat: update to 1.9.0 release" | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| - _APP_DB_ADAPTER | ||
| - _APP_DB_HOST | ||
| - _APP_DB_PORT | ||
| - _APP_DB_SCHEMA | ||
| - _APP_DB_USER | ||
| - _APP_DB_PASS | ||
| - _APP_DB_ADAPTER |
There was a problem hiding this comment.
_APP_DB_ADAPTER in every service's environment block
_APP_DB_ADAPTER is listed twice in the environment section of every service — once before _APP_DB_HOST and once after _APP_DB_PASS. This pattern repeats across all 18+ services.
Depending on the Docker Compose version in use, duplicate keys in the environment list either silently deduplicate (harmless but noisy) or produce a validation error that prevents the stack from starting. Either way, the duplicate entries should be removed.
Affected line pairs (first occurrence / duplicate):
appwrite: 100 / 106appwrite-realtime: 236 / 242appwrite-worker-audits: 267 / 273appwrite-worker-webhooks: 295 / 301appwrite-worker-deletes: 336 / 342appwrite-worker-databases: 396 / 402appwrite-worker-builds: 433 / 439appwrite-worker-functions: 543 / 549appwrite-worker-mails: 581 / 587appwrite-worker-messaging: 624 / 630appwrite-worker-migrations: 685 / 691appwrite-task-maintenance: 724 / 730appwrite-task-stats-resources: 757 / 763appwrite-worker-stats-resources: 790 / 796appwrite-worker-stats-usage: 822 / 828appwrite-task-scheduler-functions: 858 / 864appwrite-task-scheduler-executions: 887 / 893appwrite-task-scheduler-messages: 916 / 922
The second occurrence in each block (after _APP_DB_PASS) should be removed.
| - _APP_DB_ADAPTER | |
| - _APP_DB_HOST | |
| - _APP_DB_PORT | |
| - _APP_DB_SCHEMA | |
| - _APP_DB_USER | |
| - _APP_DB_PASS | |
| - _APP_DB_ADAPTER | |
| - _APP_DB_ADAPTER | |
| - _APP_DB_HOST | |
| - _APP_DB_PORT | |
| - _APP_DB_SCHEMA | |
| - _APP_DB_USER | |
| - _APP_DB_PASS | |
| - _APP_SMTP_HOST |
| services: | ||
| traefik: | ||
| image: traefik:2.11 | ||
| image: traefik:3.6 |
There was a problem hiding this comment.
Traefik 3.x introduced several breaking changes from 2.x. The Traefik command flags and service labels in this file haven't changed, so it's worth verifying compatibility:
- The
--providers.docker.constraints=Label(...)syntax is still supported in v3, but the constraint DSL did change for some expressions. PathPrefixrouter rules: In Traefik v3 the default priority calculation changed —PathPrefix("/")matching against all paths should still work, but if there are any edge cases with path priority across the console/api/realtime routers they may behave differently.- Several v2 options (e.g.
--api.insecure, some middleware configs) were removed or renamed in v3.
If manual testing verified all routes work correctly this can be ignored, but it is worth documenting the tested scenarios given how large a jump this is.
| - OPR_EXECUTOR_STORAGE_WASABI_BUCKET=$_APP_STORAGE_WASABI_BUCKET | ||
|
|
||
| mariadb: | ||
| image: mariadb:10.11 # fix issues when upgrading using: mysql_upgrade -u root -p | ||
| image: mariadb:10.11 | ||
| container_name: appwrite-mariadb |
There was a problem hiding this comment.
*x-logging anchor) was removed
The mariadb service no longer includes <<: *x-logging, which means it no longer has the json-file driver with max-size: 10m / max-file: 5 limits. Database logs can grow unboundedly on a long-running Gitpod workspace, potentially consuming significant disk space. All other services still use the anchor.
If this was intentional (e.g. the healthcheck log output needed a different driver), it's worth adding a comment explaining the decision.
1 participant
What does this PR do?
Upgrade to 1.9.0 release.
Test Plan
Manual
Related PRs and Issues
None
Have you read the Contributing Guidelines on issues?
Yes