infra: migrate mysql84-gr to dbdeployer and cap pgsql_servers max_connections#5625
infra: migrate mysql84-gr to dbdeployer and cap pgsql_servers max_connections#5625renecannao merged 18 commits intov3.0from
Conversation
Single-container MySQL 8.4.8 Group Replication infra using dbdeployer with --topology=group --single-primary. One container runs 3 mysqld nodes in a single-primary GR cluster on ports 3306/3307/3308. Key differences from master-slave: - GR topology with automatic failover - mysql_group_replication_hostgroups (4 hostgroups: writer/backup_writer/reader/offline) - Monitor user has SELECT on sys.* and performance_schema.* for GR health checks - PREFIX=30, WHG=3000, RHG=3001, BHG=3002, OHG=3003
New single-container MySQL 8.4 Group Replication infra using dbdeployer with --topology=group --single-primary. Replaces the non-existent infra-mysql84-gr with a working dbdeployer-based setup. Changes: - infra-dbdeployer-mysql84-gr: Dockerfile, entrypoint (GR topology), docker-compose, init/destroy, post scripts, ProxySQL config with mysql_group_replication_hostgroups - mysql84-gr/env.sh: set DEFAULT_MYSQL_INFRA - mysql84-gr/infras.lst: point to infra-dbdeployer-mysql84-gr - mysql84-gr/pre-proxysql.bash: rewritten to use proxysql hostname (not 127.0.0.1), dbdeployer1 servers (not mysql1/2/3), and let the framework handle infra startup GR-specific: SQL_LOG_BIN stays enabled so user creation replicates to all nodes. Monitor user has SELECT on sys.* and performance_schema.* for GR health checks.
ProxySQL was configured with pgsql_servers.max_connections=500 on BOTH
hostgroups (0 and 1) pointing at the same backend, implying a pool cap of
1000 connections against a PostgreSQL container that only allows 120
(117 non-super). Under test workload the non-super slots would fill up
and PostgreSQL rejected new Monitor connects with:
FATAL: remaining connection slots are reserved for roles with the
SUPERUSER attribute
This caused pgsql-monitor_ssl_connections_test-t (PHASE 1) and
pgsql-servers_ssl_params-t (test 33) to fail — the SSL Monitor counter
couldn't advance because the Monitor couldn't connect.
PostgreSQL doesn't scale well with connection count, so lower the
per-hostgroup cap to 50 (total 100 across the two HGs), leaving ample
headroom under PG's max_connections=120 for monitor + superuser slots.
The 500 value was templated from the MySQL/MariaDB infras during
unify-PR-5433-5442, where each backend's server-side max_connections=500
matches ProxySQL's cap. PostgreSQL here is a different beast and the
copy-paste didn't fit.
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds many new dbdeployer-based MySQL CI infra variants (multiple MySQL versions and binlog variants) including Dockerfiles, entrypoints, compose init/destroy and build scripts, post-start checks, ProxySQL SQL configs and proxy post-hooks, TAP group envs and hooks, plus a small ProxySQL pgsql max_connections reduction. Changes
Sequence Diagram(s)sequenceDiagram
participant Operator
participant Init as docker-compose-init.bash
participant Compose as Docker Compose
participant Container as dbdeployer1
participant Entrypoint as entrypoint.sh
participant MySQL as MySQL Cluster (3 nodes)
participant PostMySQL as docker-mysql-post.bash
participant ProxyPost as docker-proxy-post.bash
participant ProxySQL as proxysql.${INFRA_ID}
Operator->>Init: run init script
Init->>Compose: docker compose up -d (isolated env)
Compose->>Container: start dbdeployer1 container
Container->>Entrypoint: entrypoint runs (dbdeployer deploy)
Entrypoint->>MySQL: initialize 3-node cluster
Entrypoint->>MySQL: poll ports & MEMBER_STATE until all ONLINE
Entrypoint->>Container: touch /tmp/dbdeployer_ready
Init->>Container: check /tmp/dbdeployer_ready
Operator->>PostMySQL: run docker-mysql-post.bash
PostMySQL->>Container: docker exec mysql -e "SELECT 1" / collect ca.pem
PostMySQL->>Host: write cert bundles to infra logs
Operator->>ProxyPost: run docker-proxy-post.bash
ProxyPost->>ProxySQL: docker exec mysql -P6032 <<infra-config.sql
ProxySQL-->>ProxyPost: apply users/servers/hostgroups/debug filters
ProxyPost-->>Operator: proxy configuration complete
sequenceDiagram
participant ProxyPost as docker-proxy-post.bash
participant ProxySQL as proxysql.${INFRA_ID}
participant SQL as ./conf/proxysql/infra-config.sql
ProxyPost->>ProxySQL: docker exec mysql -P6032 (inject SQL)
ProxySQL->>SQL: execute REPLACE/INSERT/DELETE (users, servers, hostgroups, debug_filters)
ProxySQL-->>ProxyPost: LOAD/SAVE runtime→disk responses
ProxyPost-->>Operator: success / error status
Estimated code review effort🎯 5 (Critical) | ⏱️ ~120 minutes Possibly related PRs
Poem
✨ Finishing Touches🧪 Generate unit tests (beta)
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a new infrastructure setup for MySQL 8.4 Group Replication using dbdeployer, including Docker configuration, initialization scripts, and ProxySQL setup. It also updates the TAP test group for MySQL 8.4 GR and adjusts PostgreSQL connection limits. Feedback was provided regarding the run_admin function in pre-proxysql.bash where a || true prevents the retry logic from functioning correctly, and a suggestion was made to handle potential multiple directory matches when locating sandbox data in docker-mysql-post.bash.
|
|
||
| INFRA=infra-$(basename $(dirname "$0") | sed 's/-g[0-9]//' | sed 's/_.*//') | ||
| run_admin() { | ||
| docker exec ${PROXY_CONTAINER} mysql -uradmin -pradmin -h127.0.0.1 -P6032 -e "$1" 2>&1 | grep -vP 'mysql: .?Warning' || true |
There was a problem hiding this comment.
The || true at the end of the run_admin function causes it to always return a success exit code (0). This makes the wait loop on lines 23-27 ineffective, as it will always "succeed" on the first attempt even if ProxySQL is not yet reachable. Since set -o pipefail is enabled at the top of the script, removing || true will allow the function to correctly return the exit status of the mysql command, enabling the retry logic to work as intended.
docker exec "${PROXY_CONTAINER}" mysql -uradmin -pradmin -h127.0.0.1 -P6032 -e "$1" 2>&1 | grep -vP 'mysql: .?Warning'
| # Collect SSL CA certs from ALL nodes (node1, node2, node3) | ||
| # GR topology uses node1/node2/node3 (no "master" dir) | ||
| for NODE_DIR in node1 node2 node3; do | ||
| DATADIR=$(docker exec "${CONTAINER}" bash -c "ls -d /root/sandboxes/group_sp_msb_*/${NODE_DIR}/data" 2>/dev/null) |
There was a problem hiding this comment.
The wildcard group_sp_msb_*/ in the ls command could potentially match multiple sandbox directories if more than one exists in the container. This would cause the DATADIR variable to contain multiple lines, which will lead to failures in the subsequent test -f (line 49) and cat (line 51) commands. Using head -n 1 ensures that only a single path is processed.
| DATADIR=$(docker exec "${CONTAINER}" bash -c "ls -d /root/sandboxes/group_sp_msb_*/${NODE_DIR}/data" 2>/dev/null) | |
| DATADIR=$(docker exec "${CONTAINER}" bash -c "ls -d /root/sandboxes/group_sp_msb_*/${NODE_DIR}/data 2>/dev/null | head -n 1") |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (1)
test/infra/infra-dbdeployer-mysql84-gr/docker/Dockerfile (1)
24-31: Avoid duplicating the MySQL version literal in multiple places.Line 24 and Line 31 both hardcode
8.4.8. Keeping this in one variable reduces drift risk on future bumps.♻️ Suggested refactor
ARG DBDEPLOYER_VERSION=2.2.1 +ARG MYSQL_TARBALL=mysql-8.4.8-linux-glibc2.17-x86_64.tar.xz +ARG MYSQL_DIR=8.4.8 @@ RUN mkdir -p /root/opt/mysql \ - && dbdeployer downloads get-unpack mysql-8.4.8-linux-glibc2.17-x86_64.tar.xz + && dbdeployer downloads get-unpack ${MYSQL_TARBALL} @@ -ENV PATH="/root/opt/mysql/8.4.8/bin:${PATH}" +ENV PATH="/root/opt/mysql/${MYSQL_DIR}/bin:${PATH}"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql84-gr/docker/Dockerfile` around lines 24 - 31, Introduce a single ARG for the MySQL version and replace the two hardcoded occurrences: add ARG MYSQL_VERSION="8.4.8" near the top of the Dockerfile, then change the dbdeployer invocation that currently references mysql-8.4.8-linux-glibc2.17-x86_64.tar.xz to use that ARG (e.g., construct the tarball name with ${MYSQL_VERSION}) and update the ENV PATH line that points to /root/opt/mysql/8.4.8/bin to use /root/opt/mysql/${MYSQL_VERSION}/bin so version bumps only require changing MYSQL_VERSION; ensure the exact symbol names to edit are the RUN dbdeployer downloads get-unpack mysql-8.4.8... line and the ENV PATH="/root/opt/mysql/8.4.8/bin:${PATH}" line and preserve shell variable expansion style used elsewhere.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@test/infra/infra-dbdeployer-mysql84-gr/bin/docker-mysql-post.bash`:
- Around line 34-42: The current check for Group Replication uses the ONLINE
variable but only emits a warning on fewer than 3 members; change the else
branch so incomplete membership is treated as a startup failure by printing an
error and exiting non‑zero. Specifically, after the docker exec query that sets
ONLINE (referencing ONLINE, CONTAINER, ROOT_PASSWORD and the mysql SELECT
against performance_schema.replication_group_members), replace the else block
that echoes "WARNING" with a processLogger-style error message to stderr (or
echo to stderr) and call exit 1 so the script fails fast when ONLINE is not "3".
In `@test/infra/infra-dbdeployer-mysql84-gr/docker-compose-destroy.bash`:
- Around line 6-8: The script currently builds COMPOSE_PROJECT using INFRA_ID
which may be unset; update docker-compose-destroy.bash to fail fast if INFRA_ID
is empty after sourcing .env: after "set -a; . .env; set +a" check that the
environment variable INFRA_ID is defined and non-empty (e.g., test -z
"$INFRA_ID") and if it is unset print an error and exit non-zero, only then
compute COMPOSE_PROJECT="${INFRA}-${INFRA_ID}" and proceed; reference INFRA_ID
and COMPOSE_PROJECT in your check so the script never runs docker-compose down
-v against an incomplete project name.
In `@test/infra/infra-dbdeployer-mysql84-gr/docker-compose-init.bash`:
- Around line 3-8: The script currently derives INFRA_ID from the caller's
current directory (basename $(dirname $(pwd)) ...), causing non-deterministic
IDs; remove that cwd-derived fallback and instead only use an explicitly
exported INFRA_ID or a deterministic default (e.g. export INFRA_ID="dev-$USER"
or "dev-$(hostname -s)") so COMPOSE_PROJECT, network names and ROOT_PASSWORD are
reproducible; update the initialization logic around INFRA_ID (referenced
symbols: INFRA_ID, COMPOSE_PROJECT, ROOT_PASSWORD) to stop using dirname/$(pwd)
and rely solely on the environment or a stable default.
In `@test/tap/groups/mysql84-gr/pre-proxysql.bash`:
- Around line 15-17: The helper run_admin() currently swallows failures because
of the trailing "|| true"; change it so it preserves the original exit status
from the docker exec/mysql pipeline while still filtering warnings. In
run_admin(), capture the full command output and its exit code (the docker
exec/mysql pipeline), pipe the captured output through grep -vP to remove the
warning lines, print the filtered output, then return the original exit code so
callers (e.g., the readiness loop) see real failures; locate and update the
run_admin function and the docker exec mysql invocation to implement this
behavior.
- Around line 50-57: Before inserting the fixed rules, explicitly delete any
existing rows with those rule_id values to avoid duplicate-key errors: call
run_admin to DELETE FROM mysql_query_rules WHERE rule_id IN (1,2,4,5) (and
include any other hard-coded ids present) prior to the INSERT statements that
add rule_id 1,2,4,5 into mysql_query_rules; keep the subsequent LOAD MYSQL QUERY
RULES TO RUNTIME and SAVE MYSQL QUERY RULES TO DISK calls unchanged.
---
Nitpick comments:
In `@test/infra/infra-dbdeployer-mysql84-gr/docker/Dockerfile`:
- Around line 24-31: Introduce a single ARG for the MySQL version and replace
the two hardcoded occurrences: add ARG MYSQL_VERSION="8.4.8" near the top of the
Dockerfile, then change the dbdeployer invocation that currently references
mysql-8.4.8-linux-glibc2.17-x86_64.tar.xz to use that ARG (e.g., construct the
tarball name with ${MYSQL_VERSION}) and update the ENV PATH line that points to
/root/opt/mysql/8.4.8/bin to use /root/opt/mysql/${MYSQL_VERSION}/bin so version
bumps only require changing MYSQL_VERSION; ensure the exact symbol names to edit
are the RUN dbdeployer downloads get-unpack mysql-8.4.8... line and the ENV
PATH="/root/opt/mysql/8.4.8/bin:${PATH}" line and preserve shell variable
expansion style used elsewhere.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: a79ca18f-5126-4eab-af4a-75858866e975
📒 Files selected for processing (14)
test/infra/docker-pgsql16-single/conf/proxysql/config.sqltest/infra/infra-dbdeployer-mysql84-gr/.envtest/infra/infra-dbdeployer-mysql84-gr/bin/docker-mysql-post.bashtest/infra/infra-dbdeployer-mysql84-gr/bin/docker-proxy-post.bashtest/infra/infra-dbdeployer-mysql84-gr/conf/proxysql/infra-config.sqltest/infra/infra-dbdeployer-mysql84-gr/docker-compose-destroy.bashtest/infra/infra-dbdeployer-mysql84-gr/docker-compose-init.bashtest/infra/infra-dbdeployer-mysql84-gr/docker-compose.ymltest/infra/infra-dbdeployer-mysql84-gr/docker/Dockerfiletest/infra/infra-dbdeployer-mysql84-gr/docker/build.shtest/infra/infra-dbdeployer-mysql84-gr/docker/entrypoint.shtest/tap/groups/mysql84-gr/env.shtest/tap/groups/mysql84-gr/infras.lsttest/tap/groups/mysql84-gr/pre-proxysql.bash
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
- GitHub Check: CI-builds / builds (ubuntu24,-tap-genai-gcov)
- GitHub Check: CI-builds / builds (ubuntu22,-tap)
- GitHub Check: CI-builds / builds (debian12,-dbg)
- GitHub Check: run / trigger
- GitHub Check: claude-review
🧰 Additional context used
🧠 Learnings (7)
📓 Common learnings
Learnt from: wazir-ahmed
Repo: sysown/proxysql PR: 5557
File: test/tap/tests/unit/gtid_set_unit-t.cpp:14-17
Timestamp: 2026-04-01T21:27:03.216Z
Learning: In ProxySQL's unit test directory (test/tap/tests/unit/), test_globals.h and test_init.h are only required for tests that depend on the ProxySQL runtime globals/initialization (i.e., tests that exercise components linked against libproxysql.a). Pure data-structure or utility tests (e.g., ezoption_parser_unit-t.cpp, gtid_set_unit-t.cpp, gtid_trxid_interval_unit-t.cpp) only need tap.h and the relevant project header — omitting test_globals.h and test_init.h is correct and intentional in these cases.
Learnt from: CR
Repo: sysown/proxysql PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-12T11:27:41.142Z
Learning: Refer to `doc/agents/project-conventions.md` for ProxySQL-specific rules on directories, build, test harness, and git workflow
Learnt from: yuji-hatakeyama
Repo: sysown/proxysql PR: 5307
File: test/tap/tests/reg_test_5306-show_warnings_with_comment-t.cpp:39-48
Timestamp: 2026-01-20T09:34:27.165Z
Learning: In ProxySQL test files (test/tap/tests/), resource leaks (such as not calling `mysql_close()` on early return paths) are not typically fixed because test processes are short-lived and the OS frees resources on process exit. This is a common pattern across the test suite.
📚 Learning: 2026-04-12T11:27:41.142Z
Learnt from: CR
Repo: sysown/proxysql PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-12T11:27:41.142Z
Learning: Admin Interface implementation resides in `ProxySQL_Admin.cpp` and `Admin_Handler.cpp`, with schema versions tracked in `ProxySQL_Admin_Tables_Definitions.h`. Supports runtime config changes without restart via SQL-based configuration with SQLite3 backend
Applied to files:
test/infra/docker-pgsql16-single/conf/proxysql/config.sqltest/tap/groups/mysql84-gr/pre-proxysql.bashtest/infra/infra-dbdeployer-mysql84-gr/bin/docker-proxy-post.bashtest/infra/infra-dbdeployer-mysql84-gr/conf/proxysql/infra-config.sql
📚 Learning: 2026-04-12T11:27:41.142Z
Learnt from: CR
Repo: sysown/proxysql PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-12T11:27:41.142Z
Learning: Refer to `doc/agents/project-conventions.md` for ProxySQL-specific rules on directories, build, test harness, and git workflow
Applied to files:
test/infra/infra-dbdeployer-mysql84-gr/docker/build.shtest/tap/groups/mysql84-gr/pre-proxysql.bashtest/tap/groups/mysql84-gr/env.shtest/infra/infra-dbdeployer-mysql84-gr/bin/docker-proxy-post.bashtest/infra/infra-dbdeployer-mysql84-gr/conf/proxysql/infra-config.sql
📚 Learning: 2026-04-01T21:27:03.216Z
Learnt from: wazir-ahmed
Repo: sysown/proxysql PR: 5557
File: test/tap/tests/unit/gtid_set_unit-t.cpp:14-17
Timestamp: 2026-04-01T21:27:03.216Z
Learning: In ProxySQL's unit test directory (test/tap/tests/unit/), test_globals.h and test_init.h are only required for tests that depend on the ProxySQL runtime globals/initialization (i.e., tests that exercise components linked against libproxysql.a). Pure data-structure or utility tests (e.g., ezoption_parser_unit-t.cpp, gtid_set_unit-t.cpp, gtid_trxid_interval_unit-t.cpp) only need tap.h and the relevant project header — omitting test_globals.h and test_init.h is correct and intentional in these cases.
Applied to files:
test/infra/infra-dbdeployer-mysql84-gr/.envtest/tap/groups/mysql84-gr/pre-proxysql.bashtest/tap/groups/mysql84-gr/env.shtest/infra/infra-dbdeployer-mysql84-gr/conf/proxysql/infra-config.sql
📚 Learning: 2026-01-20T09:34:27.165Z
Learnt from: yuji-hatakeyama
Repo: sysown/proxysql PR: 5307
File: test/tap/tests/reg_test_5306-show_warnings_with_comment-t.cpp:39-48
Timestamp: 2026-01-20T09:34:27.165Z
Learning: In ProxySQL test files (test/tap/tests/), resource leaks (such as not calling `mysql_close()` on early return paths) are not typically fixed because test processes are short-lived and the OS frees resources on process exit. This is a common pattern across the test suite.
Applied to files:
test/tap/groups/mysql84-gr/pre-proxysql.bashtest/tap/groups/mysql84-gr/env.shtest/infra/infra-dbdeployer-mysql84-gr/bin/docker-proxy-post.bash
📚 Learning: 2026-01-20T07:40:34.938Z
Learnt from: yuji-hatakeyama
Repo: sysown/proxysql PR: 5307
File: test/tap/tests/reg_test_5306-show_warnings_with_comment-t.cpp:24-28
Timestamp: 2026-01-20T07:40:34.938Z
Learning: In ProxySQL test files, calling `mysql_error(NULL)` after `mysql_init()` failure is safe because the MariaDB client library implementation returns an empty string for NULL handles (not undefined behavior).
Applied to files:
test/tap/groups/mysql84-gr/pre-proxysql.bashtest/tap/groups/mysql84-gr/env.shtest/infra/infra-dbdeployer-mysql84-gr/conf/proxysql/infra-config.sql
📚 Learning: 2026-04-12T11:27:41.142Z
Learnt from: CR
Repo: sysown/proxysql PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-12T11:27:41.142Z
Learning: Applies to **/*.{cpp,h,hpp} : Feature tiers controlled by flags: `PROXYSQL31=1` for v3.1.x (FFTO, TSDB), `PROXYSQLGENAI=1` for v4.0.x (GenAI, MCP, Anomaly Detection). `PROXYSQLGENAI=1` implies `PROXYSQL31=1` which implies `PROXYSQLFFTO=1` and `PROXYSQLTSDB=1`
Applied to files:
test/tap/groups/mysql84-gr/pre-proxysql.bashtest/infra/infra-dbdeployer-mysql84-gr/conf/proxysql/infra-config.sql
🪛 dotenv-linter (4.0.0)
test/infra/infra-dbdeployer-mysql84-gr/.env
[warning] 6-6: [UnorderedKey] The RHG key should go before the WHG key
(UnorderedKey)
[warning] 7-7: [UnorderedKey] The BHG key should go before the RHG key
(UnorderedKey)
[warning] 8-8: [UnorderedKey] The OHG key should go before the RHG key
(UnorderedKey)
🪛 Shellcheck (0.11.0)
test/tap/groups/mysql84-gr/pre-proxysql.bash
[info] 16-16: Double quote to prevent globbing and word splitting.
(SC2086)
[info] 25-25: Double quote to prevent globbing and word splitting.
(SC2086)
test/infra/infra-dbdeployer-mysql84-gr/docker-compose-destroy.bash
[warning] 4-4: Quote this to prevent word splitting.
(SC2046)
[info] 4-4: Double quote to prevent globbing and word splitting.
(SC2086)
[info] 6-6: Not following: .env was not specified as input (see shellcheck -x).
(SC1091)
test/infra/infra-dbdeployer-mysql84-gr/bin/docker-proxy-post.bash
[info] 5-5: Not following: ./../.env was not specified as input (see shellcheck -x).
(SC1091)
[style] 56-56: Check exit code directly with e.g. 'if mycmd;', not indirectly with $?.
(SC2181)
test/infra/infra-dbdeployer-mysql84-gr/bin/docker-mysql-post.bash
[info] 4-4: Not following: .env was not specified as input (see shellcheck -x).
(SC1091)
test/infra/infra-dbdeployer-mysql84-gr/docker-compose-init.bash
[warning] 4-4: Declare and assign separately to avoid masking return values.
(SC2155)
[warning] 4-4: Quote this to prevent word splitting.
(SC2046)
[warning] 4-4: Quote this to prevent word splitting.
(SC2046)
[warning] 24-24: Quote this to prevent word splitting.
(SC2046)
[info] 24-24: Double quote to prevent globbing and word splitting.
(SC2086)
[warning] 24-24: Expanding an array without an index only gives the first element.
(SC2128)
[warning] 27-27: Quote this to prevent word splitting.
(SC2046)
[info] 27-27: Double quote to prevent globbing and word splitting.
(SC2086)
[info] 33-33: Not following: .env was not specified as input (see shellcheck -x).
(SC1091)
[warning] 48-48: Declare and assign separately to avoid masking return values.
(SC2155)
test/infra/infra-dbdeployer-mysql84-gr/docker/entrypoint.sh
[info] 10-10: Use find instead of ls to better handle non-alphanumeric filenames.
(SC2012)
[info] 39-39: Use find instead of ls to better handle non-alphanumeric filenames.
(SC2012)
[info] 60-60: Double quote to prevent globbing and word splitting.
(SC2086)
🪛 Trivy (0.69.3)
test/infra/infra-dbdeployer-mysql84-gr/docker/Dockerfile
[error] 1-1: Image user should not be 'root'
Specify at least 1 USER command in Dockerfile with non-root user as argument
Rule: DS-0002
(IaC/Dockerfile)
🔇 Additional comments (10)
test/infra/infra-dbdeployer-mysql84-gr/.env (1)
1-15: Looks good — hostgroup derivation and TAP export are coherent.No functional concerns in this segment.
test/infra/infra-dbdeployer-mysql84-gr/conf/proxysql/infra-config.sql (1)
8-24: GR hostgroup/server wiring is correctly aligned with the dbdeployer topology.The cleanup + reinsert pattern and hostgroup mapping are consistent with the new single-container 3-node setup.
test/tap/groups/mysql84-gr/infras.lst (1)
1-1: Infra selector update is correct and consistent with the new group environment.test/infra/docker-pgsql16-single/conf/proxysql/config.sql (1)
2-3: Good fix — cappingpgsql_servers.max_connectionshere is appropriate for the container limits.test/tap/groups/mysql84-gr/env.sh (1)
1-3: Environment defaults are correctly set for the migrated mysql84-gr infra.test/infra/infra-dbdeployer-mysql84-gr/docker-compose.yml (1)
3-19: Compose service/network configuration is consistent with the init/post scripts.test/infra/infra-dbdeployer-mysql84-gr/docker/build.sh (1)
1-8: Build helper script is clear and functionally sound for local image creation.test/infra/infra-dbdeployer-mysql84-gr/docker/Dockerfile (1)
1-38: Overall Dockerfile flow is solid for the intended dbdeployer-based test image.test/infra/infra-dbdeployer-mysql84-gr/docker/entrypoint.sh (1)
84-138: Verify the elected primary before running the bootstrap SQL.This block assumes port
3306is always writable.--single-primaryguarantees one primary, but not necessarily thatnode1remains it; if election lands elsewhere, the user/database setup runs on a read-only member and readiness never completes.Safer pattern
+PRIMARY_PORT="" +for PORT in "${NODE_PORTS[@]}"; do + if [ "$(${MYSQL_CMD} -P"${PORT}" --batch -N -e "SELECT @@global.super_read_only")" = "0" ]; then + PRIMARY_PORT="${PORT}" + break + fi +done + +[ -n "${PRIMARY_PORT}" ] || { echo "ERROR: No writable primary found"; exit 1; } + -echo "Creating test users on primary (port 3306)..." +echo "Creating test users on primary (port ${PRIMARY_PORT})..." -${MYSQL_CMD} -P3306 <<SQL +${MYSQL_CMD} -P"${PRIMARY_PORT}" <<SQLtest/tap/groups/mysql84-gr/pre-proxysql.bash (1)
12-13: NormalizeDEFAULT_MYSQL_INFRAbefore using it inMYSQL_HOST.
env.shfor this group setsDEFAULT_MYSQL_INFRAwith a leading/. Concatenating it directly here yieldsdbdeployer1./infra-dbdeployer-mysql84-gr, so themysql_servers.hostnameentries are invalid.Proposed fix
INFRA="${DEFAULT_MYSQL_INFRA:-infra-dbdeployer-mysql84-gr}" +INFRA="${INFRA#/}" MYSQL_HOST="${MYSQL_PRIMARY_HOST:-dbdeployer1}.${INFRA}"
| # Verify Group Replication status | ||
| echo -n "Checking Group Replication status..." | ||
| ONLINE=$(docker exec "${CONTAINER}" mysql -h127.0.0.1 -P3306 -uroot -p"${ROOT_PASSWORD}" --batch -N -e \ | ||
| "SELECT COUNT(*) FROM performance_schema.replication_group_members WHERE MEMBER_STATE='ONLINE'" 2>/dev/null) | ||
| if [ "$ONLINE" = "3" ]; then | ||
| echo " OK (3 members ONLINE)" | ||
| else | ||
| echo " WARNING (only $ONLINE members ONLINE)" | ||
| fi |
There was a problem hiding this comment.
Treat incomplete GR membership as a startup failure.
This script is part of the infra readiness path. Logging a warning and continuing with fewer than 3 ONLINE members turns a broken cluster into later test flakiness.
Proposed fix
if [ "$ONLINE" = "3" ]; then
echo " OK (3 members ONLINE)"
else
- echo " WARNING (only $ONLINE members ONLINE)"
+ echo " FAILED (only $ONLINE members ONLINE)"
+ exit 1
fi📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # Verify Group Replication status | |
| echo -n "Checking Group Replication status..." | |
| ONLINE=$(docker exec "${CONTAINER}" mysql -h127.0.0.1 -P3306 -uroot -p"${ROOT_PASSWORD}" --batch -N -e \ | |
| "SELECT COUNT(*) FROM performance_schema.replication_group_members WHERE MEMBER_STATE='ONLINE'" 2>/dev/null) | |
| if [ "$ONLINE" = "3" ]; then | |
| echo " OK (3 members ONLINE)" | |
| else | |
| echo " WARNING (only $ONLINE members ONLINE)" | |
| fi | |
| # Verify Group Replication status | |
| echo -n "Checking Group Replication status..." | |
| ONLINE=$(docker exec "${CONTAINER}" mysql -h127.0.0.1 -P3306 -uroot -p"${ROOT_PASSWORD}" --batch -N -e \ | |
| "SELECT COUNT(*) FROM performance_schema.replication_group_members WHERE MEMBER_STATE='ONLINE'" 2>/dev/null) | |
| if [ "$ONLINE" = "3" ]; then | |
| echo " OK (3 members ONLINE)" | |
| else | |
| echo " FAILED (only $ONLINE members ONLINE)" | |
| exit 1 | |
| fi |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/infra/infra-dbdeployer-mysql84-gr/bin/docker-mysql-post.bash` around
lines 34 - 42, The current check for Group Replication uses the ONLINE variable
but only emits a warning on fewer than 3 members; change the else branch so
incomplete membership is treated as a startup failure by printing an error and
exiting non‑zero. Specifically, after the docker exec query that sets ONLINE
(referencing ONLINE, CONTAINER, ROOT_PASSWORD and the mysql SELECT against
performance_schema.replication_group_members), replace the else block that
echoes "WARNING" with a processLogger-style error message to stderr (or echo to
stderr) and call exit 1 so the script fails fast when ONLINE is not "3".
| set -a; . .env; set +a | ||
| export INFRA=${PWD##*/} | ||
| export COMPOSE_PROJECT="${INFRA}-${INFRA_ID}" |
There was a problem hiding this comment.
Fail fast when INFRA_ID is unset.
This infra's .env does not define INFRA_ID, so COMPOSE_PROJECT becomes incomplete here unless the caller exported it. In that case down -v targets the wrong project and leaves the started stack behind.
Proposed fix
set -a; . .env; set +a
+if [ -z "${INFRA_ID}" ]; then
+ echo "ERROR: INFRA_ID must be set"
+ exit 1
+fi
export INFRA=${PWD##*/}
export COMPOSE_PROJECT="${INFRA}-${INFRA_ID}"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| set -a; . .env; set +a | |
| export INFRA=${PWD##*/} | |
| export COMPOSE_PROJECT="${INFRA}-${INFRA_ID}" | |
| set -a; . .env; set +a | |
| if [ -z "${INFRA_ID}" ]; then | |
| echo "ERROR: INFRA_ID must be set" | |
| exit 1 | |
| fi | |
| export INFRA=${PWD##*/} | |
| export COMPOSE_PROJECT="${INFRA}-${INFRA_ID}" |
🧰 Tools
🪛 Shellcheck (0.11.0)
[info] 6-6: Not following: .env was not specified as input (see shellcheck -x).
(SC1091)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/infra/infra-dbdeployer-mysql84-gr/docker-compose-destroy.bash` around
lines 6 - 8, The script currently builds COMPOSE_PROJECT using INFRA_ID which
may be unset; update docker-compose-destroy.bash to fail fast if INFRA_ID is
empty after sourcing .env: after "set -a; . .env; set +a" check that the
environment variable INFRA_ID is defined and non-empty (e.g., test -z
"$INFRA_ID") and if it is unset print an error and exit non-zero, only then
compute COMPOSE_PROJECT="${INFRA}-${INFRA_ID}" and proceed; reference INFRA_ID
and COMPOSE_PROJECT in your check so the script never runs docker-compose down
-v against an incomplete project name.
| if [ -z "${INFRA_ID}" ]; then | ||
| export INFRA_ID=$(basename $(dirname $(pwd)) | sed 's/infra-//; s/docker-//') | ||
| fi | ||
| # Final safety: if INFRA_ID is still empty or ".", use a default | ||
| if [ -z "${INFRA_ID}" ] || [ "${INFRA_ID}" = "." ]; then | ||
| export INFRA_ID="dev-$USER" |
There was a problem hiding this comment.
Don't derive INFRA_ID from the caller's current directory.
This fallback parses dirname $(pwd), so invoking the same script from repo root vs. the infra directory yields different IDs. Since INFRA_ID also feeds COMPOSE_PROJECT, network names, and the generated ROOT_PASSWORD, unset-env runs become non-deterministic.
Proposed fix
-# RELIABLY CAPTURE INFRA_ID FROM ENVIRONMENT OR DIRECTORY NAME
-if [ -z "${INFRA_ID}" ]; then
- export INFRA_ID=$(basename $(dirname $(pwd)) | sed 's/infra-//; s/docker-//')
-fi
-# Final safety: if INFRA_ID is still empty or ".", use a default
-if [ -z "${INFRA_ID}" ] || [ "${INFRA_ID}" = "." ]; then
- export INFRA_ID="dev-$USER"
-fi
+if [ -z "${INFRA_ID}" ]; then
+ export INFRA_ID="dev-${USER}"
+fi🧰 Tools
🪛 Shellcheck (0.11.0)
[warning] 4-4: Declare and assign separately to avoid masking return values.
(SC2155)
[warning] 4-4: Quote this to prevent word splitting.
(SC2046)
[warning] 4-4: Quote this to prevent word splitting.
(SC2046)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/infra/infra-dbdeployer-mysql84-gr/docker-compose-init.bash` around lines
3 - 8, The script currently derives INFRA_ID from the caller's current directory
(basename $(dirname $(pwd)) ...), causing non-deterministic IDs; remove that
cwd-derived fallback and instead only use an explicitly exported INFRA_ID or a
deterministic default (e.g. export INFRA_ID="dev-$USER" or "dev-$(hostname -s)")
so COMPOSE_PROJECT, network names and ROOT_PASSWORD are reproducible; update the
initialization logic around INFRA_ID (referenced symbols: INFRA_ID,
COMPOSE_PROJECT, ROOT_PASSWORD) to stop using dirname/$(pwd) and rely solely on
the environment or a stable default.
| run_admin() { | ||
| docker exec ${PROXY_CONTAINER} mysql -uradmin -pradmin -h127.0.0.1 -P6032 -e "$1" 2>&1 | grep -vP 'mysql: .?Warning' || true | ||
| } |
There was a problem hiding this comment.
Preserve the real exit code in run_admin().
The trailing || true makes this helper succeed even when docker exec or mysql fails. That lets the readiness loop on Lines 23-26 print OK immediately and turns every later admin change into best-effort.
Proposed fix
run_admin() {
- docker exec ${PROXY_CONTAINER} mysql -uradmin -pradmin -h127.0.0.1 -P6032 -e "$1" 2>&1 | grep -vP 'mysql: .?Warning' || true
+ local output rc
+ if output=$(docker exec "${PROXY_CONTAINER}" mysql -uradmin -pradmin -h127.0.0.1 -P6032 -e "$1" 2>&1); then
+ rc=0
+ else
+ rc=$?
+ fi
+ printf '%s\n' "${output}" | grep -vP 'mysql: .?Warning' || true
+ return "${rc}"
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| run_admin() { | |
| docker exec ${PROXY_CONTAINER} mysql -uradmin -pradmin -h127.0.0.1 -P6032 -e "$1" 2>&1 | grep -vP 'mysql: .?Warning' || true | |
| } | |
| run_admin() { | |
| local output rc | |
| if output=$(docker exec "${PROXY_CONTAINER}" mysql -uradmin -pradmin -h127.0.0.1 -P6032 -e "$1" 2>&1); then | |
| rc=0 | |
| else | |
| rc=$? | |
| fi | |
| printf '%s\n' "${output}" | grep -vP 'mysql: .?Warning' || true | |
| return "${rc}" | |
| } |
🧰 Tools
🪛 Shellcheck (0.11.0)
[info] 16-16: Double quote to prevent globbing and word splitting.
(SC2086)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/tap/groups/mysql84-gr/pre-proxysql.bash` around lines 15 - 17, The
helper run_admin() currently swallows failures because of the trailing "||
true"; change it so it preserves the original exit status from the docker
exec/mysql pipeline while still filtering warnings. In run_admin(), capture the
full command output and its exit code (the docker exec/mysql pipeline), pipe the
captured output through grep -vP to remove the warning lines, print the filtered
output, then return the original exit code so callers (e.g., the readiness loop)
see real failures; locate and update the run_admin function and the docker exec
mysql invocation to implement this behavior.
| run_admin " | ||
| DELETE FROM mysql_query_rules WHERE destination_hostgroup IN (0,1,2,3,4); | ||
| INSERT INTO mysql_query_rules (rule_id,active,username,match_digest,destination_hostgroup,apply) VALUES (1,1,'root','^SELECT.*FOR UPDATE',0,1); | ||
| INSERT INTO mysql_query_rules (rule_id,active,username,match_digest,destination_hostgroup,apply) VALUES (2,1,'root','^SELECT',1,1); | ||
| INSERT INTO mysql_query_rules (rule_id,active,username,match_digest,destination_hostgroup,apply) VALUES (4,1,'testuser','^SELECT.*FOR UPDATE',0,1); | ||
| INSERT INTO mysql_query_rules (rule_id,active,username,match_digest,destination_hostgroup,apply) VALUES (5,1,'testuser','^SELECT',1,1); | ||
| LOAD MYSQL QUERY RULES TO RUNTIME; | ||
| SAVE MYSQL QUERY RULES TO DISK; |
There was a problem hiding this comment.
Delete by rule_id before reinserting these fixed rules.
These inserts hard-code rule_ids 1,2,4,5, but the cleanup only removes rows routed to hostgroups 0-4. Any stale rule with one of those IDs on another destination hostgroup will make this hook fail with a duplicate-key error.
Proposed fix
-DELETE FROM mysql_query_rules WHERE destination_hostgroup IN (0,1,2,3,4);
+DELETE FROM mysql_query_rules
+WHERE rule_id IN (1,2,4,5)
+ OR destination_hostgroup IN (0,1,2,3,4);🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/tap/groups/mysql84-gr/pre-proxysql.bash` around lines 50 - 57, Before
inserting the fixed rules, explicitly delete any existing rows with those
rule_id values to avoid duplicate-key errors: call run_admin to DELETE FROM
mysql_query_rules WHERE rule_id IN (1,2,4,5) (and include any other hard-coded
ids present) prior to the INSERT statements that add rule_id 1,2,4,5 into
mysql_query_rules; keep the subsequent LOAD MYSQL QUERY RULES TO RUNTIME and
SAVE MYSQL QUERY RULES TO DISK calls unchanged.
… infras
Mirrors the existing mysql84 / mysql84-gr layout (single-container dbdeployer
sandboxes) for MySQL 9.0, 9.3, and 9.5 — both standalone replication and
Group Replication variants.
New infrastructures:
test/infra/infra-dbdeployer-mysql{90,93,95}/ — standalone replication (3 nodes)
test/infra/infra-dbdeployer-mysql{90,93,95}-gr/ — Group Replication (3 nodes, single-primary)
Hostgroup PREFIX assignment (continuing the existing convention):
mysql90 PREFIX=31 (WHG/RHG/BHG/OHG = 3100/3101/3102/3103)
mysql93 PREFIX=32 (3200/3201/3202/3203)
mysql95 PREFIX=33 (3300/3301/3302/3303)
mysql90-gr PREFIX=34 (3400/3401/3402/3403)
mysql93-gr PREFIX=35 (3500/3501/3502/3503)
mysql95-gr PREFIX=36 (3600/3601/3602/3603)
MySQL 9.x tarballs (via dbdeployer downloads get-unpack) use glibc2.28
(9.x no longer ships glibc2.17 bundles):
mysql-9.0.1-linux-glibc2.28-x86_64.tar.xz
mysql-9.3.0-linux-glibc2.28-x86_64.tar.xz
mysql-9.5.0-linux-glibc2.28-x86_64.tar.xz
MySQL 9.x compatibility notes:
- mysql_native_password was removed in MySQL 9.0. Dropped both the
-c mysql_native_password=ON dbdeployer flag and the IDENTIFIED WITH
'mysql_native_password' clause from CREATE USER / ALTER USER; users
now use the server default (caching_sha2_password).
ProxySQL may need SSL to authenticate to 9.x backends because
caching_sha2_password requires either SSL or a preconfigured RSA key.
This is left to follow-up tuning — flagging here for visibility.
Group wiring (test/tap/groups/):
mysql{90,93,95}/ — env.sh + infras.lst + setup-infras.bash + pre-proxysql.bash (no-op)
mirror mysql84/ exactly, only the infra/group names differ
mysql{90,93,95}-gr/ — env.sh + infras.lst + pre-proxysql.bash
mirror mysql84-gr/; pre-proxysql.bash uses docker exec
to configure ProxySQL with GR fallback HGs + users + rules
groups.json: registered mysql95-g1 and mysql95-gr-g1 (16 tests each),
identical test sets to the existing mysql93-g1 / mysql93-gr-g1 entries.
check_groups.py reports 385/385 tests registered, no orphans.
No changes touching existing infras; only new files + groups.json append.
Validated with `python3 test/tap/groups/check_groups.py`.
There was a problem hiding this comment.
Actionable comments posted: 18
Note
Due to the large number of review comments, Critical, Major severity comments were prioritized as inline comments.
🟡 Minor comments (3)
test/infra/infra-dbdeployer-mysql93/docker-compose-destroy.bash-4-4 (1)
4-4:⚠️ Potential issue | 🟡 MinorQuote the
pushdpath expansion to avoid split/glob bugs.
pushd $(dirname $0)can misbehave with whitespace or special characters in script paths. Use fully quoted expansion:pushd "$(dirname "$0")" &>/dev/nullSuggested fix
-pushd $(dirname $0) &>/dev/null +pushd "$(dirname "$0")" &>/dev/null🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql93/docker-compose-destroy.bash` at line 4, The pushd call uses unquoted path expansion (pushd $(dirname $0)) which can break on spaces or special chars; update the command to use quoted expansions for both dirname and $0 (i.e., pushd "$(dirname "$0")" &>/dev/null) so the path is treated as a single argument and globbing/splitting is avoided.test/infra/infra-dbdeployer-mysql90-gr/docker-compose-destroy.bash-4-4 (1)
4-4:⚠️ Potential issue | 🟡 MinorQuote
dirnameexpansion inpushd.On Line 4, quoting is needed to prevent path splitting/globbing edge cases.
Suggested fix
-pushd $(dirname $0) &>/dev/null +pushd "$(dirname "$0")" &>/dev/null🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql90-gr/docker-compose-destroy.bash` at line 4, The pushd call uses an unquoted dirname expansion which can cause word-splitting or globbing; update the invocation that uses pushd and dirname (the pushd $(dirname $0) expression) to quote the dirname expansion and the $0 variable so the entire path is treated as a single argument (i.e., ensure dirname and its result are wrapped in quotes) to prevent path splitting/globbing edge cases.test/infra/infra-dbdeployer-mysql95/docker-compose-destroy.bash-4-4 (1)
4-4:⚠️ Potential issue | 🟡 MinorQuote path expansion in
pushdto avoid word-splitting bugs.On Line 4, unquoted
$(dirname $0)can break if the path contains spaces or glob characters.Suggested fix
-pushd $(dirname $0) &>/dev/null +pushd "$(dirname "$0")" &>/dev/null🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql95/docker-compose-destroy.bash` at line 4, The unquoted pushd command uses $(dirname $0) which can break on paths with spaces or glob characters; fix the invocation in the docker-compose-destroy.bash script by passing "$0" to dirname and wrapping the command substitution in double quotes (i.e., quote the result of dirname when calling pushd) so pushd receives a single, properly-quoted path.
🧹 Nitpick comments (19)
test/tap/groups/mysql90/env.sh (1)
7-10: Optional: add a local fallback whenWORKSPACEis unset.Current logic works for CI, but local runs can silently skip infra
.envloading and miss TAP vars.Possible fallback pattern
if [ -n "${WORKSPACE}" ]; then _INFRA_ENV="${WORKSPACE}/test/infra/${DEFAULT_MYSQL_INFRA}/.env" [ -f "${_INFRA_ENV}" ] && . "${_INFRA_ENV}" +else + _GROUP_DIR="$(cd "$(dirname "$0")" && pwd)" + _INFRA_ENV="${_GROUP_DIR}/../../infra/${DEFAULT_MYSQL_INFRA}/.env" + [ -f "${_INFRA_ENV}" ] && . "${_INFRA_ENV}" fi🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/tap/groups/mysql90/env.sh` around lines 7 - 10, When WORKSPACE may be unset, add a local fallback so the infra .env is sourced for local runs: detect if WORKSPACE is empty and set it to a sensible default (e.g., project root via git rev-parse --show-toplevel or script directory using dirname "$0") before constructing _INFRA_ENV; then preserve the existing logic that builds _INFRA_ENV from DEFAULT_MYSQL_INFRA and sources it if present. Update the block that references WORKSPACE, _INFRA_ENV and DEFAULT_MYSQL_INFRA to set the fallback WORKSPACE value when unset and then proceed to check and source _INFRA_ENV.test/tap/groups/mysql95-gr/pre-proxysql.bash (2)
15-17: Quote variable to prevent word splitting.Same as the mysql90-gr variant - quote
${PROXY_CONTAINER}for defensive coding.🔧 Suggested fix
run_admin() { - docker exec ${PROXY_CONTAINER} mysql -uradmin -pradmin -h127.0.0.1 -P6032 -e "$1" 2>&1 | grep -vP 'mysql: .?Warning' || true + docker exec "${PROXY_CONTAINER}" mysql -uradmin -pradmin -h127.0.0.1 -P6032 -e "$1" 2>&1 | grep -vP 'mysql: .?Warning' || true }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/tap/groups/mysql95-gr/pre-proxysql.bash` around lines 15 - 17, The run_admin function uses an unquoted variable when calling docker exec; change the invocation to quote the container variable (replace usage of ${PROXY_CONTAINER} with "${PROXY_CONTAINER}") inside run_admin so the docker exec call is safe from word-splitting or globbing, keeping the existing quoting of "$1" and the rest of the pipeline intact.
23-27: Quote loop variable in comparison.🔧 Suggested fix
for i in $(seq 1 30); do if run_admin "SELECT 1" >/dev/null 2>&1; then echo " OK"; break; fi - if [ $i -eq 30 ]; then echo " TIMEOUT"; exit 1; fi + if [ "$i" -eq 30 ]; then echo " TIMEOUT"; exit 1; fi echo -n "."; sleep 1 done🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/tap/groups/mysql95-gr/pre-proxysql.bash` around lines 23 - 27, The comparison in the retry loop uses an unquoted loop variable (i) which can cause a shell error if empty; update the test in the block that contains `if [ $i -eq 30 ]; then ...` to quote the variable (e.g. use `"$i"`) so the numeric comparison is robust, leaving the rest of the loop (the `for i in $(seq 1 30); do`, `run_admin "SELECT 1"`, and timeout handling) unchanged.test/tap/groups/mysql90-gr/pre-proxysql.bash (2)
15-17: Quote variable to prevent word splitting.The
${PROXY_CONTAINER}variable should be quoted to prevent potential word splitting issues if the container name ever contains spaces or special characters.🔧 Suggested fix
run_admin() { - docker exec ${PROXY_CONTAINER} mysql -uradmin -pradmin -h127.0.0.1 -P6032 -e "$1" 2>&1 | grep -vP 'mysql: .?Warning' || true + docker exec "${PROXY_CONTAINER}" mysql -uradmin -pradmin -h127.0.0.1 -P6032 -e "$1" 2>&1 | grep -vP 'mysql: .?Warning' || true }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/tap/groups/mysql90-gr/pre-proxysql.bash` around lines 15 - 17, The run_admin() helper uses unquoted ${PROXY_CONTAINER} which can lead to word-splitting; update the docker exec invocation in run_admin() to quote the container variable (use "${PROXY_CONTAINER}") so the container name is passed as a single argument, keeping the existing quoted "$1" and the rest of the pipeline unchanged.
23-27: Quote loop variable in comparison.The variable
$ishould be quoted in the comparison for consistency with shell best practices.🔧 Suggested fix
for i in $(seq 1 30); do if run_admin "SELECT 1" >/dev/null 2>&1; then echo " OK"; break; fi - if [ $i -eq 30 ]; then echo " TIMEOUT"; exit 1; fi + if [ "$i" -eq 30 ]; then echo " TIMEOUT"; exit 1; fi echo -n "."; sleep 1 done🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/tap/groups/mysql90-gr/pre-proxysql.bash` around lines 23 - 27, The shell comparison uses an unquoted loop variable which can break in edge cases; update the conditional in the retry loop that reads if [ $i -eq 30 ] to quote the variable (use "$i") so the comparison becomes if [ "$i" -eq 30 ] and ensure any similar bracket tests in the same loop use quoted variables (e.g., referencing i in run_admin checks or echo statements) to follow shell best practices.test/infra/infra-dbdeployer-mysql90-gr/docker/entrypoint.sh (1)
59-69: Quote${MYSQL_CMD}variable for robustness.Same quoting concern as mysql93-gr variant.
🔧 Alternative using array-based approach
-MYSQL_CMD="mysql -h127.0.0.1 -uroot -p${DBDEPLOYER_ROOT_PASS}" +MYSQL_OPTS=(-h127.0.0.1 -uroot "-p${DBDEPLOYER_ROOT_PASS}") ... - while ! ${MYSQL_CMD} -P${PORT} -e "SELECT 1" >/dev/null 2>&1; do + while ! mysql "${MYSQL_OPTS[@]}" -P"${PORT}" -e "SELECT 1" >/dev/null 2>&1; do🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql90-gr/docker/entrypoint.sh` around lines 59 - 69, The shell loop uses an unquoted command substitution ${MYSQL_CMD}; make it robust by quoting or using an array to prevent word-splitting and globbing when invoking the client in the while test—update the loop invocation that currently reads while ! ${MYSQL_CMD} -P${PORT} -e "SELECT 1" ... to call the quoted/array form (e.g., use "${MYSQL_CMD}" or an array like MYSQL_CMD=(mysql ...) and use "${MYSQL_CMD[@]}" -P"${PORT}" -e "SELECT 1") so the commands referencing MYSQL_CMD, PORT, COUNT and MAX_WAIT run safely under all values.test/infra/infra-dbdeployer-mysql93/docker/entrypoint.sh (1)
61-71: Quote${MYSQL_CMD}variable for robustness.Same quoting concern as the GR variant - the
${MYSQL_CMD}variable relies on word splitting.🔧 Alternative using explicit command
- while ! ${MYSQL_CMD} -P${PORT} -e "SELECT 1" >/dev/null 2>&1; do + while ! mysql -h127.0.0.1 -uroot "-p${DBDEPLOYER_ROOT_PASS}" -P"${PORT}" -e "SELECT 1" >/dev/null 2>&1; do🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql93/docker/entrypoint.sh` around lines 61 - 71, The loop uses an unquoted variable expansion ${MYSQL_CMD} which can break if the command contains spaces or arguments; update the check in the while to quote or use an explicit command array so the invocation is robust (e.g., invoke "${MYSQL_CMD}" -P"${PORT}" -e "SELECT 1" or convert MYSQL_CMD into an array and call it as "${MYSQL_CMD[@]}" -P"${PORT}" -e "SELECT 1"); ensure PORT, COUNT and MAX_WAIT remain quoted where interpolated (e.g., -P"${PORT}" and [ "$COUNT" -ge "$MAX_WAIT" ]) and keep the rest of the loop logic in function/entrypoint.sh the same.test/infra/infra-dbdeployer-mysql90-gr/bin/docker-mysql-post.bash (1)
22-31: Quote port variable for consistency.Same quoting suggestion as the mysql93 variant.
🔧 Suggested fix
- while ! docker exec "${CONTAINER}" mysql -h127.0.0.1 -P${PORT} -uroot -p"${ROOT_PASSWORD}" -e "SELECT 1" >/dev/null 2>&1; do + while ! docker exec "${CONTAINER}" mysql -h127.0.0.1 -P"${PORT}" -uroot -p"${ROOT_PASSWORD}" -e "SELECT 1" >/dev/null 2>&1; do🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql90-gr/bin/docker-mysql-post.bash` around lines 22 - 31, The docker exec health-check loop uses an unquoted port expansion (-P${PORT}) which can break if PORT contains spaces or special chars; update the command inside the while to quote the port option (change -P${PORT} to -P"${PORT}") while leaving "${CONTAINER}" and "-p\"${ROOT_PASSWORD}\"" as-is so the variables CONTAINER, PORT, ROOT_PASSWORD, COUNT and MAX_WAIT are all handled safely and consistently.test/infra/infra-dbdeployer-mysql93/bin/docker-mysql-post.bash (1)
22-31: Quote port variable for consistency.The
-P${PORT}should be quoted as-P"${PORT}"for consistency with shell best practices, even though port numbers won't contain special characters.🔧 Suggested fix
- while ! docker exec "${CONTAINER}" mysql -h127.0.0.1 -P${PORT} -uroot -p"${ROOT_PASSWORD}" -e "SELECT 1" >/dev/null 2>&1; do + while ! docker exec "${CONTAINER}" mysql -h127.0.0.1 -P"${PORT}" -uroot -p"${ROOT_PASSWORD}" -e "SELECT 1" >/dev/null 2>&1; do🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql93/bin/docker-mysql-post.bash` around lines 22 - 31, The docker exec invocation uses an unquoted port flag (-P${PORT}); update that to -P"${PORT}" in the while loop command to match the existing quoting of variables (CONTAINER, ROOT_PASSWORD) and follow shell best practices—i.e., change the string inside the while condition that calls docker exec to quote ${PORT} as "${PORT}" so the line becomes: docker exec "${CONTAINER}" mysql -h127.0.0.1 -P"${PORT}" -uroot -p"${ROOT_PASSWORD}" -e "SELECT 1" >/dev/null 2>&1; ensuring consistency with COUNT and MAX_WAIT logic unchanged.test/infra/infra-dbdeployer-mysql93-gr/docker/entrypoint.sh (1)
59-69: Quote${MYSQL_CMD}variable to prevent word splitting.The
${MYSQL_CMD}variable contains spaces (the fullmysql -h127.0.0.1 -uroot -p...command), so it relies on word splitting to work. This is intentional but fragile. Consider using an array or quoting the port separately.🔧 Alternative using explicit command
-MYSQL_CMD="mysql -h127.0.0.1 -uroot -p${DBDEPLOYER_ROOT_PASS}" +MYSQL_OPTS=(-h127.0.0.1 -uroot "-p${DBDEPLOYER_ROOT_PASS}") NODE_PORTS=(3306 3307 3308) NODE_NAMES=("node1" "node2" "node3") # Wait for all 3 nodes to accept connections for i in 0 1 2; do PORT="${NODE_PORTS[$i]}" NAME="${NODE_NAMES[$i]}" echo -n "Waiting for ${NAME} on port ${PORT}..." MAX_WAIT=60 COUNT=0 - while ! ${MYSQL_CMD} -P${PORT} -e "SELECT 1" >/dev/null 2>&1; do + while ! mysql "${MYSQL_OPTS[@]}" -P"${PORT}" -e "SELECT 1" >/dev/null 2>&1; do🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql93-gr/docker/entrypoint.sh` around lines 59 - 69, The loop uses an unquoted string variable MYSQL_CMD which can break on word splitting; change MYSQL_CMD to an array of command + args (e.g. MYSQL_CMD=(mysql -h127.0.0.1 -uroot -p"$PASSWORD")) and invoke it as "${MYSQL_CMD[@]}" -P"$PORT" -e "SELECT 1" in the while test (or alternatively keep a single command name and pass host/user/password as separate quoted variables), and ensure PORT is quoted as -P"$PORT" to avoid word-splitting issues in the loop that uses MYSQL_CMD and PORT.test/tap/groups/mysql93-gr/pre-proxysql.bash (2)
15-17: Quote variables in docker exec command.Per Shellcheck SC2086, quote
${PROXY_CONTAINER}to prevent potential word splitting issues.Proposed fix
run_admin() { - docker exec ${PROXY_CONTAINER} mysql -uradmin -pradmin -h127.0.0.1 -P6032 -e "$1" 2>&1 | grep -vP 'mysql: .?Warning' || true + docker exec "${PROXY_CONTAINER}" mysql -uradmin -pradmin -h127.0.0.1 -P6032 -e "$1" 2>&1 | grep -vP 'mysql: .?Warning' || true }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/tap/groups/mysql93-gr/pre-proxysql.bash` around lines 15 - 17, The run_admin function uses an unquoted ${PROXY_CONTAINER} in the docker exec command which can cause word-splitting; update the command in run_admin to quote the container variable (i.e., use "${PROXY_CONTAINER}") so the docker exec invocation is robust against spaces or glob characters, leaving the rest of the command intact (including the mysql args and the grep/pipe).
23-27: Quote loop variable for robustness.Per Shellcheck SC2086, quote
$ito prevent word splitting, though the risk is minimal withseqoutput.Proposed fix
for i in $(seq 1 30); do if run_admin "SELECT 1" >/dev/null 2>&1; then echo " OK"; break; fi - if [ $i -eq 30 ]; then echo " TIMEOUT"; exit 1; fi + if [ "$i" -eq 30 ]; then echo " TIMEOUT"; exit 1; fi echo -n "."; sleep 1 done🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/tap/groups/mysql93-gr/pre-proxysql.bash` around lines 23 - 27, The test loop uses an unquoted loop variable ($i) in the numeric comparison ([ $i -eq 30 ]) which triggers ShellCheck SC2086; update the conditional to quote the variable (use [ "$i" -eq 30 ]) so word-splitting is avoided, leaving the rest of the loop (for i in $(seq 1 30), run_admin invocation, echo/sleep) unchanged.test/infra/infra-dbdeployer-mysql95-gr/conf/proxysql/infra-config.sql (1)
10-13: Inconsistentmax_connectionsacross infra configs.The
mysql_serversinserts here omitmax_connections, while the non-GR variant (infra-dbdeployer-mysql95/conf/proxysql/infra-config.sql) explicitly setsmax_connections=500. This may cause different connection pooling behavior between GR and non-GR test infrastructures.Consider adding
max_connectionsfor consistency:Proposed fix
-INSERT INTO mysql_servers (hostgroup_id,hostname,port,max_replication_lag,comment) VALUES (${WHG},'dbdeployer1.${INFRA}',3306,1,'dbdeployer1.${INFRA}'); -INSERT INTO mysql_servers (hostgroup_id,hostname,port,max_replication_lag,comment) VALUES (${RHG},'dbdeployer1.${INFRA}',3306,1,'dbdeployer1.${INFRA}'); -INSERT INTO mysql_servers (hostgroup_id,hostname,port,max_replication_lag,comment) VALUES (${RHG},'dbdeployer1.${INFRA}',3307,1,'dbdeployer1.${INFRA}'); -INSERT INTO mysql_servers (hostgroup_id,hostname,port,max_replication_lag,comment) VALUES (${RHG},'dbdeployer1.${INFRA}',3308,1,'dbdeployer1.${INFRA}'); +INSERT INTO mysql_servers (hostgroup_id,hostname,port,max_replication_lag,max_connections,comment) VALUES (${WHG},'dbdeployer1.${INFRA}',3306,1,500,'dbdeployer1.${INFRA}'); +INSERT INTO mysql_servers (hostgroup_id,hostname,port,max_replication_lag,max_connections,comment) VALUES (${RHG},'dbdeployer1.${INFRA}',3306,1,500,'dbdeployer1.${INFRA}'); +INSERT INTO mysql_servers (hostgroup_id,hostname,port,max_replication_lag,max_connections,comment) VALUES (${RHG},'dbdeployer1.${INFRA}',3307,1,500,'dbdeployer1.${INFRA}'); +INSERT INTO mysql_servers (hostgroup_id,hostname,port,max_replication_lag,max_connections,comment) VALUES (${RHG},'dbdeployer1.${INFRA}',3308,1,500,'dbdeployer1.${INFRA}');🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql95-gr/conf/proxysql/infra-config.sql` around lines 10 - 13, The mysql_servers INSERTs in this GR config (rows inserting into mysql_servers) omit the max_connections column causing inconsistent pooling vs the non-GR infra (compare infra-dbdeployer-mysql95/conf/proxysql/infra-config.sql which sets max_connections=500); update each INSERT in this file (the four INSERT INTO mysql_servers statements) to include the max_connections column/value (e.g., max_connections=500) so the column list and VALUES match the non-GR variant for consistent behavior.test/infra/infra-dbdeployer-mysql95/bin/docker-proxy-post.bash (1)
56-56: Consider checking exit status directly.Per Shellcheck SC2181, prefer checking the command's exit status directly rather than via
$?. This is a minor style improvement.Proposed fix
-if [ $? -eq 0 ]; then echo "Cluster ${INFRA} registered in ProxySQL."; else echo "ERROR: ProxySQL configuration FAILED for ${INFRA}"; exit 1; fi +if docker exec -i "${PROXY_CONTAINER}" mysql -uadmin -padmin -h127.0.0.1 -P6032 <<SQL +$(eval "echo \"$(cat ./conf/proxysql/infra-config.sql)\"") +... +SQL +then + echo "Cluster ${INFRA} registered in ProxySQL." +else + echo "ERROR: ProxySQL configuration FAILED for ${INFRA}" + exit 1 +fiAlternatively, since
set -eis enabled, the script will exit on failure anyway, making the explicit check somewhat redundant.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql95/bin/docker-proxy-post.bash` at line 56, Replace the explicit `$?` test in the ProxySQL registration check with a direct command status check: modify the `if [ $? -eq 0 ]; then ... fi` that follows the cluster registration call to test the registration command itself (e.g., `if <registration-command>; then`) so the shell evaluates the command's exit status directly; alternatively, if `set -e` is relied upon, remove the conditional entirely and let the script exit on failure, but do not leave a `$?`-based test. Ensure the change still uses the INFRA variable in the success/error messages.test/infra/infra-dbdeployer-mysql90-gr/bin/docker-proxy-post.bash (1)
10-11: Resolveinfra-config.sqlviaSCRIPT_DIR.Line 11 reads
./conf/proxysql/infra-config.sqlfrom the caller's cwd, so invoking this hook directly from anywhere except the infra root will fail even though Line 4 already computes the script location.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql90-gr/bin/docker-proxy-post.bash` around lines 10 - 11, The command is reading "./conf/proxysql/infra-config.sql" relative to the caller's cwd; update the docker exec heredoc invocation to reference the already-computed SCRIPT_DIR so the file is resolved from the script location (use SCRIPT_DIR when building the path to infra-config.sql) and ensure the substitution still uses the existing eval/echo/cat pattern (i.e., replace ./conf/proxysql/infra-config.sql with "${SCRIPT_DIR}/conf/proxysql/infra-config.sql" in the docker exec / $(eval "echo \"$(cat ... )\"") sequence).test/infra/infra-dbdeployer-mysql93-gr/bin/docker-proxy-post.bash (1)
10-11: Resolveinfra-config.sqlviaSCRIPT_DIR.Line 11 reads
./conf/proxysql/infra-config.sqlfrom the caller's cwd, so invoking this hook directly from anywhere except the infra root will fail even though Line 4 already computes the script location.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql93-gr/bin/docker-proxy-post.bash` around lines 10 - 11, The script reads ./conf/proxysql/infra-config.sql relative to the caller cwd; change it to use the precomputed SCRIPT_DIR so the file is resolved correctly regardless of cwd. Update the docker exec input substitution that currently uses $(eval "echo \"$(cat ./conf/proxysql/infra-config.sql)\"") to read from "${SCRIPT_DIR}/conf/proxysql/infra-config.sql" instead (preserving the eval/echo wrapping and quoting) so the infra-config.sql path is always resolved via SCRIPT_DIR.test/infra/infra-dbdeployer-mysql95-gr/bin/docker-proxy-post.bash (2)
14-28:INSERT OR IGNOREis redundant afterDELETE.The pattern of
DELETE FROM mysql_users WHERE username='root'followed byINSERT OR IGNOREmeans theOR IGNOREclause never triggers—the row was just deleted, so the insert always succeeds.This works correctly but the
OR IGNOREis misleading. Consider using plainINSERTorINSERT OR REPLACEfor clearer intent.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql95-gr/bin/docker-proxy-post.bash` around lines 14 - 28, The SQL uses DELETE FROM mysql_users ... then INSERT OR IGNORE INTO mysql_users (...) VALUES (...) which makes OR IGNORE redundant; update the INSERT statements that follow the DELETE (the ones inserting 'root', 'testuser', and '${INFRA}' into mysql_users) to use the clearer intent—either plain INSERT INTO mysql_users (...) VALUES (...) if you expect the row to be newly created, or INSERT OR REPLACE INTO mysql_users (...) VALUES (...) if you intend to overwrite any existing entry—so replace the three occurrences of "INSERT OR IGNORE INTO mysql_users" accordingly while keeping the same columns/values (e.g., references to ${ROOT_PASSWORD}, ${WHG}, ${INFRA} remain unchanged).
56-56: Unreachable error handling due toset -e.With
set -eenabled on line 2, if thedocker execcommand (lines 10-54) fails, the script exits immediately before reaching this line. Theelsebranch can never execute, making this check misleading.Per shellcheck SC2181, prefer checking the exit code directly:
♻️ Suggested simplification
-if [ $? -eq 0 ]; then echo "Cluster ${INFRA} registered in ProxySQL."; else echo "ERROR: ProxySQL configuration FAILED for ${INFRA}"; exit 1; fi +echo "Cluster ${INFRA} registered in ProxySQL."Or if you want explicit error handling, disable
set -efor that command:set +e docker exec -i "${PROXY_CONTAINER}" mysql -uadmin -padmin -h127.0.0.1 -P6032 <<SQL ... SQL if [ $? -ne 0 ]; then echo "ERROR: ProxySQL configuration FAILED for ${INFRA}" exit 1 fi set -e echo "Cluster ${INFRA} registered in ProxySQL."🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql95-gr/bin/docker-proxy-post.bash` at line 56, The final if/else is unreachable because set -e causes the script to exit if the docker exec block fails; update the logic around the docker exec (the here-doc that runs against "${PROXY_CONTAINER}") to capture its exit status explicitly: either wrap that command in an if ...; then ...; else ...; fi construct (i.e., if docker exec -i "${PROXY_CONTAINER}" mysql ... <<SQL; then echo "Cluster ${INFRA} registered in ProxySQL."; else echo "ERROR: ProxySQL configuration FAILED for ${INFRA}"; exit 1; fi) or temporarily disable errexit (set +e) before docker exec, check $? and re-enable set -e, ensuring you reference the "${PROXY_CONTAINER}" docker exec invocation and "${INFRA}" in the messages.test/infra/infra-dbdeployer-mysql93/docker-compose-init.bash (1)
48-48: Declare and assign separately to avoid masking return values (SC2155).If
sha256sumfails, the error is masked by the immediate assignment toROOT_PASSWORD.♻️ Suggested fix
-export ROOT_PASSWORD=$(echo -n "${INFRA_ID}" | sha256sum | head -c 10) +ROOT_PASSWORD=$(echo -n "${INFRA_ID}" | sha256sum | head -c 10) +export ROOT_PASSWORD🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql93/docker-compose-init.bash` at line 48, The export line that assigns ROOT_PASSWORD via command substitution (export ROOT_PASSWORD=$(echo -n "${INFRA_ID}" | sha256sum | head -c 10)) masks any failure from sha256sum (SC2155); instead, first run the pipeline and capture its output into a local variable (e.g., tmp or root_pw), check the command exit status and handle errors, then export ROOT_PASSWORD from that verified variable so failures aren’t hidden and the script can fail or log an error before exporting.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@test/infra/infra-dbdeployer-mysql90-gr/docker-compose-init.bash`:
- Around line 2-14: INFRA_ID is being derived from the caller's cwd (basename
$(dirname $(pwd))) which is wrong; compute SCRIPT_DIR first and derive INFRA_ID
from the script path (use dirname of SCRIPT_DIR) or move the
SCRIPT_DIR/SCRIPT_DIR-derived REPO_ROOT logic above the INFRA_ID block, then set
INFRA_ID with basename "$(dirname "$SCRIPT_DIR")" (or equivalent using dirname
"${SCRIPT_DIR}") so INFRA_ID is stable and based on the script location; keep
the existing fallback to "dev-$USER" unchanged.
- Around line 36-44: The script currently hardcodes the dbdeployer container
name (`${COMPOSE_PROJECT}-dbdeployer1-1`), which can drift from docker-compose;
instead use the already-detected COMPOSE_CMD and COMPOSE_PROJECT to discover the
container ID dynamically (e.g., run `docker compose ps -q dbdeployer1` via
COMPOSE_CMD) and assign it to a CONTAINER variable, then use that CONTAINER
variable wherever the hardcoded name was used; update references in the script
that used `${COMPOSE_PROJECT}-dbdeployer1-1` to use the resolved CONTAINER.
In `@test/infra/infra-dbdeployer-mysql90-gr/docker/Dockerfile`:
- Around line 18-20: The curl|tar pipeline that downloads dbdeployer using the
DBDEPLOYER_VERSION env var should include integrity verification: first check
whether a published SHA256 (or GPG signature) exists for the specific dbdeployer
release; if a SHA256 is available, download the checksum alongside the tarball
and verify it (e.g., via sha256sum -c) before extracting to
/usr/local/bin/dbdeployer, or if a signed artifact exists verify via gpg; if no
checksum/signature is published, add a short documented justification in
CI/Docker build docs that TLS (ca-certificates) is relied upon and note the
accepted risk for these dbdeployer artifacts.
In `@test/infra/infra-dbdeployer-mysql90/bin/docker-mysql-post.bash`:
- Around line 35-44: The loop that checks replication (variables PORT,
REPLICA_STATUS, IO_RUNNING, SQL_RUNNING, using docker exec against CONTAINER
with ROOT_PASSWORD) currently only prints a warning for unhealthy replicas;
modify it so that when either IO_RUNNING or SQL_RUNNING is not "Yes" you print a
clear error message including the port and statuses and then fail the script
(exit with non‑zero, e.g. exit 1) so the post-check aborts on unhealthy
replication; alternatively accumulate failures in a flag and call exit 1 after
the loop if any port failed.
In `@test/infra/infra-dbdeployer-mysql90/bin/docker-proxy-post.bash`:
- Around line 10-11: The script uses a relative path
"./conf/proxysql/infra-config.sql" which depends on the caller's CWD; fix
docker-proxy-post.bash to compute the script directory (e.g., via DIR="$(cd
"$(dirname "${BASH_SOURCE[0]:-$0}")" && pwd)") and replace
"./conf/proxysql/infra-config.sql" with a script-relative path like
"$DIR/conf/proxysql/infra-config.sql" when constructing the heredoc passed to
docker exec (the command that uses ${PROXY_CONTAINER} and the eval/cat
invocation).
In `@test/infra/infra-dbdeployer-mysql90/docker-compose-init.bash`:
- Around line 2-14: The INFRA_ID derivation should use the script path instead
of the caller's cwd: replace the use of dirname $(pwd) with a dirname based on
SCRIPT_DIR or REPO_ROOT (e.g. export INFRA_ID=$(basename "$(dirname
"${SCRIPT_DIR}")" | sed 's/infra-//; s/docker-//') or use dirname "${REPO_ROOT}"
if that better matches your repo layout), ensure the expression is quoted and
preserves the existing sed normalization, and keep the existing fallback that
sets INFRA_ID="dev-$USER" when the result is empty or ".".
In `@test/infra/infra-dbdeployer-mysql93-gr/docker/Dockerfile`:
- Around line 18-20: The Dockerfile currently pipes the downloaded dbdeployer
tarball directly into tar which skips integrity checks; instead download the
tarball and its corresponding SHA256 checksum for the release (using
DBDEPLOYER_VERSION to build the URL), verify the tarball with sha256sum (or by
comparing the checksum content) and only proceed to extract and chmod +x
/usr/local/bin/dbdeployer if the checksum verification succeeds; ensure the
commands fail the build on mismatch and remove any temporary files after
extraction so the dbdeployer installation path and DBDEPLOYER_VERSION are used
to locate and verify the correct artifact.
In `@test/infra/infra-dbdeployer-mysql93/bin/docker-proxy-post.bash`:
- Around line 10-11: The script reads infra-config.sql from the current working
directory instead of the script directory; update the docker exec heredoc
command in docker-proxy-post.bash to use the script-dir variable (SCRIPT_DIR)
when resolving the file (e.g., replace ./conf/proxysql/infra-config.sql with
"${SCRIPT_DIR}/conf/proxysql/infra-config.sql" or compute SCRIPT_DIR via dirname
"$0" if not present) so the eval "echo \"$(cat ... )\"" loads the correct file
regardless of the caller's CWD.
In `@test/infra/infra-dbdeployer-mysql93/docker-compose-init.bash`:
- Around line 3-9: The INFRA_ID derivation currently uses basename $(dirname
$(pwd)) which yields the parent dir ("infra") for all infra folders; change it
to derive from the current directory by using basename "$(pwd)" and strip
prefixes with sed as before, e.g. assign INFRA_DIR=$(basename "$(pwd)");
INFRA_ID=$(echo "$INFRA_DIR" | sed 's/infra-//; s/docker-//'); export INFRA_ID;
ensure command substitutions are quoted to fix SC2046 and split
declaration/assignment to avoid SC2155 (do not export and assign in one
statement), and keep the existing fallback that sets INFRA_ID="dev-$USER" when
empty or ".".
In `@test/infra/infra-dbdeployer-mysql93/docker/Dockerfile`:
- Around line 18-20: Download the dbdeployer tarball and its published SHA256
checksum (using DBDEPLOYER_VERSION), compute and verify the tarball's SHA256
before extracting to /usr/local/bin/dbdeployer, and fail the build if the
checksum does not match; update the existing curl|tar pipeline to first curl the
.tar.gz and its .sha256 (or .sha256sum) into files, run a sha256sum -c (or
compare computed sha256) against the expected value, then only extract and chmod
/usr/local/bin/dbdeployer on success; apply this same checksum-verification
change to all 12 dbdeployer Dockerfiles that use DBDEPLOYER_VERSION and
/usr/local/bin/dbdeployer.
In `@test/infra/infra-dbdeployer-mysql95-gr/docker-compose-init.bash`:
- Around line 2-14: The INFRA_ID fallback currently derives from the caller's
cwd using dirname $(pwd), which is fragile; change the logic to compute INFRA_ID
from the script path (use SCRIPT_DIR/REPO_ROOT) instead: when INFRA_ID is empty,
derive it from the directory name of SCRIPT_DIR or REPO_ROOT (strip
infra-/docker- prefixes as done now), and keep the final safety default to
"dev-$USER"; update the block that sets INFRA_ID (referencing INFRA_ID,
SCRIPT_DIR, REPO_ROOT, and WORKSPACE) so the infra identifier is determined from
the script location rather than the caller's working directory.
- Around line 36-44: Replace the hardcoded container name with a dynamic lookup:
instead of using the literal "${COMPOSE_PROJECT}-dbdeployer1-1", call the
resolved compose command in COMPOSE_CMD to find the service container (e.g.
container_id="$($COMPOSE_CMD ps -q dbdeployer1)" and then get the actual
container name with docker inspect --format '{{.Name}}' "$container_id" or use
$COMPOSE_CMD ps --format '{{.Name}}' to obtain the name), and use that value
wherever the script currently uses the hardcoded container name; update the code
that currently references the literal name to compute and reuse this
dynamically-resolved container name so changes to container_name in the compose
file won’t break the script.
In `@test/infra/infra-dbdeployer-mysql95-gr/docker/Dockerfile`:
- Around line 18-20: Download the dbdeployer archive to a temporary file instead
of streaming, also fetch the corresponding checksums file from the same GitHub
release and verify the archive's checksum (use DBDEPLOYER_VERSION to build the
release URL and match the expected entry) before extracting; only after a
successful checksum verification extract the tarball into /usr/local/bin/ and
chmod +x /usr/local/bin/dbdeployer, and fail the build if verification does not
match.
In `@test/infra/infra-dbdeployer-mysql95/docker-compose-init.bash`:
- Around line 2-14: The INFRA_ID derivation currently uses dirname $(pwd) which
reflects the caller's cwd; change it to derive from the script path by using
SCRIPT_DIR (or its parent directory) instead—replace the line setting INFRA_ID
from basename $(dirname $(pwd)) with a basename of the parent dir of SCRIPT_DIR
(then pipe through sed 's/infra-//; s/docker-//') so INFRA_ID is based on the
script location; keep the existing fallback check that sets INFRA_ID="dev-$USER"
and leave SCRIPT_DIR, REPO_ROOT, and WORKSPACE logic unchanged.
In `@test/infra/infra-dbdeployer-mysql95/docker/entrypoint.sh`:
- Around line 54-71: The script currently only waits for sockets to accept
connections (loop over NODE_PORTS/NODE_NAMES using MYSQL_CMD) but then creates
/tmp/dbdeployer_ready before checking replication; update the entrypoint so that
after the existing port-wait loop you add a second health check for the replica
nodes (ports from NODE_PORTS for nodes 1 and 2) that repeatedly runs MYSQL_CMD
-P${PORT} -e "SHOW SLAVE STATUS\G" (MySQL5.7) and parses for Slave_IO_Running:
Yes and Slave_SQL_Running: Yes (or the equivalent replica fields) with a similar
MAX_WAIT/COUNT timeout and retries; only create /tmp/dbdeployer_ready once both
replicas report IO and SQL running, and fail the script (exit 1) on timeout,
keeping references to MYSQL_CMD, NODE_PORTS, NODE_NAMES, and
/tmp/dbdeployer_ready so the change is easy to locate.
In `@test/tap/groups/mysql90/setup-infras.bash`:
- Around line 21-25: The cp command uses a '*' glob that will fail under set -e
if the source directory is empty; update the copy to tolerate empty directories
by replacing the glob-based copy of WORKSPACE/.../reg_test_3223_scripts/* with a
directory-content copy (e.g., copy from the reg_test_3223_scripts directory
itself using the "copy contents" form or switch to rsync -a) into
PROXY_DATA_DIR/reg_test_3223_scripts so the operation succeeds even when the
source has no files; keep the existing mkdir -p for PROXY_DATA_DIR and preserve
permissions handling for script_no_permissions.
In `@test/tap/groups/mysql93/setup-infras.bash`:
- Around line 21-25: The cp command that uses the glob "*" can fail under set -e
when the source directory exists but is empty; update the copy in the
mysql93/setup-infras.bash to use the dot-copy form (copy the directory contents
with "/." — e.g., cp -r "${WORKSPACE}/test/tap/tests/reg_test_3223_scripts/."
"${PROXY_DATA_DIR}/reg_test_3223_scripts/") so empty directories are handled
safely, and apply the identical change to the same cp occurrences in
legacy/setup-infras.bash, mysql84/setup-infras.bash, mysql90/setup-infras.bash,
and mysql95/setup-infras.bash (referencing the cp invocation that uses
"${WORKSPACE}/test/tap/tests/reg_test_3223_scripts" and the target
"${PROXY_DATA_DIR}/reg_test_3223_scripts").
In `@test/tap/groups/mysql95/setup-infras.bash`:
- Around line 21-25: The copy uses a glob that fails when the source dir is
empty; replace the fragile cp -r "${WORKSPACE}/.../"* usage in the setup hook
for reg_test_3223_scripts with a robust dot-copy approach (use cp -a with the
source directory’s dot notation) and ensure the target dir
(${PROXY_DATA_DIR}/reg_test_3223_scripts) is created beforehand; apply the same
fix to the corresponding copies in mysql90/setup-infras.bash and
mysql93/setup-infras.bash so the scripts won't exit under set -e when the source
is empty.
---
Minor comments:
In `@test/infra/infra-dbdeployer-mysql90-gr/docker-compose-destroy.bash`:
- Line 4: The pushd call uses an unquoted dirname expansion which can cause
word-splitting or globbing; update the invocation that uses pushd and dirname
(the pushd $(dirname $0) expression) to quote the dirname expansion and the $0
variable so the entire path is treated as a single argument (i.e., ensure
dirname and its result are wrapped in quotes) to prevent path splitting/globbing
edge cases.
In `@test/infra/infra-dbdeployer-mysql93/docker-compose-destroy.bash`:
- Line 4: The pushd call uses unquoted path expansion (pushd $(dirname $0))
which can break on spaces or special chars; update the command to use quoted
expansions for both dirname and $0 (i.e., pushd "$(dirname "$0")" &>/dev/null)
so the path is treated as a single argument and globbing/splitting is avoided.
In `@test/infra/infra-dbdeployer-mysql95/docker-compose-destroy.bash`:
- Line 4: The unquoted pushd command uses $(dirname $0) which can break on paths
with spaces or glob characters; fix the invocation in the
docker-compose-destroy.bash script by passing "$0" to dirname and wrapping the
command substitution in double quotes (i.e., quote the result of dirname when
calling pushd) so pushd receives a single, properly-quoted path.
---
Nitpick comments:
In `@test/infra/infra-dbdeployer-mysql90-gr/bin/docker-mysql-post.bash`:
- Around line 22-31: The docker exec health-check loop uses an unquoted port
expansion (-P${PORT}) which can break if PORT contains spaces or special chars;
update the command inside the while to quote the port option (change -P${PORT}
to -P"${PORT}") while leaving "${CONTAINER}" and "-p\"${ROOT_PASSWORD}\"" as-is
so the variables CONTAINER, PORT, ROOT_PASSWORD, COUNT and MAX_WAIT are all
handled safely and consistently.
In `@test/infra/infra-dbdeployer-mysql90-gr/bin/docker-proxy-post.bash`:
- Around line 10-11: The command is reading "./conf/proxysql/infra-config.sql"
relative to the caller's cwd; update the docker exec heredoc invocation to
reference the already-computed SCRIPT_DIR so the file is resolved from the
script location (use SCRIPT_DIR when building the path to infra-config.sql) and
ensure the substitution still uses the existing eval/echo/cat pattern (i.e.,
replace ./conf/proxysql/infra-config.sql with
"${SCRIPT_DIR}/conf/proxysql/infra-config.sql" in the docker exec / $(eval "echo
\"$(cat ... )\"") sequence).
In `@test/infra/infra-dbdeployer-mysql90-gr/docker/entrypoint.sh`:
- Around line 59-69: The shell loop uses an unquoted command substitution
${MYSQL_CMD}; make it robust by quoting or using an array to prevent
word-splitting and globbing when invoking the client in the while test—update
the loop invocation that currently reads while ! ${MYSQL_CMD} -P${PORT} -e
"SELECT 1" ... to call the quoted/array form (e.g., use "${MYSQL_CMD}" or an
array like MYSQL_CMD=(mysql ...) and use "${MYSQL_CMD[@]}" -P"${PORT}" -e
"SELECT 1") so the commands referencing MYSQL_CMD, PORT, COUNT and MAX_WAIT run
safely under all values.
In `@test/infra/infra-dbdeployer-mysql93-gr/bin/docker-proxy-post.bash`:
- Around line 10-11: The script reads ./conf/proxysql/infra-config.sql relative
to the caller cwd; change it to use the precomputed SCRIPT_DIR so the file is
resolved correctly regardless of cwd. Update the docker exec input substitution
that currently uses $(eval "echo \"$(cat ./conf/proxysql/infra-config.sql)\"")
to read from "${SCRIPT_DIR}/conf/proxysql/infra-config.sql" instead (preserving
the eval/echo wrapping and quoting) so the infra-config.sql path is always
resolved via SCRIPT_DIR.
In `@test/infra/infra-dbdeployer-mysql93-gr/docker/entrypoint.sh`:
- Around line 59-69: The loop uses an unquoted string variable MYSQL_CMD which
can break on word splitting; change MYSQL_CMD to an array of command + args
(e.g. MYSQL_CMD=(mysql -h127.0.0.1 -uroot -p"$PASSWORD")) and invoke it as
"${MYSQL_CMD[@]}" -P"$PORT" -e "SELECT 1" in the while test (or alternatively
keep a single command name and pass host/user/password as separate quoted
variables), and ensure PORT is quoted as -P"$PORT" to avoid word-splitting
issues in the loop that uses MYSQL_CMD and PORT.
In `@test/infra/infra-dbdeployer-mysql93/bin/docker-mysql-post.bash`:
- Around line 22-31: The docker exec invocation uses an unquoted port flag
(-P${PORT}); update that to -P"${PORT}" in the while loop command to match the
existing quoting of variables (CONTAINER, ROOT_PASSWORD) and follow shell best
practices—i.e., change the string inside the while condition that calls docker
exec to quote ${PORT} as "${PORT}" so the line becomes: docker exec
"${CONTAINER}" mysql -h127.0.0.1 -P"${PORT}" -uroot -p"${ROOT_PASSWORD}" -e
"SELECT 1" >/dev/null 2>&1; ensuring consistency with COUNT and MAX_WAIT logic
unchanged.
In `@test/infra/infra-dbdeployer-mysql93/docker-compose-init.bash`:
- Line 48: The export line that assigns ROOT_PASSWORD via command substitution
(export ROOT_PASSWORD=$(echo -n "${INFRA_ID}" | sha256sum | head -c 10)) masks
any failure from sha256sum (SC2155); instead, first run the pipeline and capture
its output into a local variable (e.g., tmp or root_pw), check the command exit
status and handle errors, then export ROOT_PASSWORD from that verified variable
so failures aren’t hidden and the script can fail or log an error before
exporting.
In `@test/infra/infra-dbdeployer-mysql93/docker/entrypoint.sh`:
- Around line 61-71: The loop uses an unquoted variable expansion ${MYSQL_CMD}
which can break if the command contains spaces or arguments; update the check in
the while to quote or use an explicit command array so the invocation is robust
(e.g., invoke "${MYSQL_CMD}" -P"${PORT}" -e "SELECT 1" or convert MYSQL_CMD into
an array and call it as "${MYSQL_CMD[@]}" -P"${PORT}" -e "SELECT 1"); ensure
PORT, COUNT and MAX_WAIT remain quoted where interpolated (e.g., -P"${PORT}" and
[ "$COUNT" -ge "$MAX_WAIT" ]) and keep the rest of the loop logic in
function/entrypoint.sh the same.
In `@test/infra/infra-dbdeployer-mysql95-gr/bin/docker-proxy-post.bash`:
- Around line 14-28: The SQL uses DELETE FROM mysql_users ... then INSERT OR
IGNORE INTO mysql_users (...) VALUES (...) which makes OR IGNORE redundant;
update the INSERT statements that follow the DELETE (the ones inserting 'root',
'testuser', and '${INFRA}' into mysql_users) to use the clearer intent—either
plain INSERT INTO mysql_users (...) VALUES (...) if you expect the row to be
newly created, or INSERT OR REPLACE INTO mysql_users (...) VALUES (...) if you
intend to overwrite any existing entry—so replace the three occurrences of
"INSERT OR IGNORE INTO mysql_users" accordingly while keeping the same
columns/values (e.g., references to ${ROOT_PASSWORD}, ${WHG}, ${INFRA} remain
unchanged).
- Line 56: The final if/else is unreachable because set -e causes the script to
exit if the docker exec block fails; update the logic around the docker exec
(the here-doc that runs against "${PROXY_CONTAINER}") to capture its exit status
explicitly: either wrap that command in an if ...; then ...; else ...; fi
construct (i.e., if docker exec -i "${PROXY_CONTAINER}" mysql ... <<SQL; then
echo "Cluster ${INFRA} registered in ProxySQL."; else echo "ERROR: ProxySQL
configuration FAILED for ${INFRA}"; exit 1; fi) or temporarily disable errexit
(set +e) before docker exec, check $? and re-enable set -e, ensuring you
reference the "${PROXY_CONTAINER}" docker exec invocation and "${INFRA}" in the
messages.
In `@test/infra/infra-dbdeployer-mysql95-gr/conf/proxysql/infra-config.sql`:
- Around line 10-13: The mysql_servers INSERTs in this GR config (rows inserting
into mysql_servers) omit the max_connections column causing inconsistent pooling
vs the non-GR infra (compare
infra-dbdeployer-mysql95/conf/proxysql/infra-config.sql which sets
max_connections=500); update each INSERT in this file (the four INSERT INTO
mysql_servers statements) to include the max_connections column/value (e.g.,
max_connections=500) so the column list and VALUES match the non-GR variant for
consistent behavior.
In `@test/infra/infra-dbdeployer-mysql95/bin/docker-proxy-post.bash`:
- Line 56: Replace the explicit `$?` test in the ProxySQL registration check
with a direct command status check: modify the `if [ $? -eq 0 ]; then ... fi`
that follows the cluster registration call to test the registration command
itself (e.g., `if <registration-command>; then`) so the shell evaluates the
command's exit status directly; alternatively, if `set -e` is relied upon,
remove the conditional entirely and let the script exit on failure, but do not
leave a `$?`-based test. Ensure the change still uses the INFRA variable in the
success/error messages.
In `@test/tap/groups/mysql90-gr/pre-proxysql.bash`:
- Around line 15-17: The run_admin() helper uses unquoted ${PROXY_CONTAINER}
which can lead to word-splitting; update the docker exec invocation in
run_admin() to quote the container variable (use "${PROXY_CONTAINER}") so the
container name is passed as a single argument, keeping the existing quoted "$1"
and the rest of the pipeline unchanged.
- Around line 23-27: The shell comparison uses an unquoted loop variable which
can break in edge cases; update the conditional in the retry loop that reads if
[ $i -eq 30 ] to quote the variable (use "$i") so the comparison becomes if [
"$i" -eq 30 ] and ensure any similar bracket tests in the same loop use quoted
variables (e.g., referencing i in run_admin checks or echo statements) to follow
shell best practices.
In `@test/tap/groups/mysql90/env.sh`:
- Around line 7-10: When WORKSPACE may be unset, add a local fallback so the
infra .env is sourced for local runs: detect if WORKSPACE is empty and set it to
a sensible default (e.g., project root via git rev-parse --show-toplevel or
script directory using dirname "$0") before constructing _INFRA_ENV; then
preserve the existing logic that builds _INFRA_ENV from DEFAULT_MYSQL_INFRA and
sources it if present. Update the block that references WORKSPACE, _INFRA_ENV
and DEFAULT_MYSQL_INFRA to set the fallback WORKSPACE value when unset and then
proceed to check and source _INFRA_ENV.
In `@test/tap/groups/mysql93-gr/pre-proxysql.bash`:
- Around line 15-17: The run_admin function uses an unquoted ${PROXY_CONTAINER}
in the docker exec command which can cause word-splitting; update the command in
run_admin to quote the container variable (i.e., use "${PROXY_CONTAINER}") so
the docker exec invocation is robust against spaces or glob characters, leaving
the rest of the command intact (including the mysql args and the grep/pipe).
- Around line 23-27: The test loop uses an unquoted loop variable ($i) in the
numeric comparison ([ $i -eq 30 ]) which triggers ShellCheck SC2086; update the
conditional to quote the variable (use [ "$i" -eq 30 ]) so word-splitting is
avoided, leaving the rest of the loop (for i in $(seq 1 30), run_admin
invocation, echo/sleep) unchanged.
In `@test/tap/groups/mysql95-gr/pre-proxysql.bash`:
- Around line 15-17: The run_admin function uses an unquoted variable when
calling docker exec; change the invocation to quote the container variable
(replace usage of ${PROXY_CONTAINER} with "${PROXY_CONTAINER}") inside run_admin
so the docker exec call is safe from word-splitting or globbing, keeping the
existing quoting of "$1" and the rest of the pipeline intact.
- Around line 23-27: The comparison in the retry loop uses an unquoted loop
variable (i) which can cause a shell error if empty; update the test in the
block that contains `if [ $i -eq 30 ]; then ...` to quote the variable (e.g. use
`"$i"`) so the numeric comparison is robust, leaving the rest of the loop (the
`for i in $(seq 1 30); do`, `run_admin "SELECT 1"`, and timeout handling)
unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 20f06db0-7140-401d-9310-600f3ca6e609
📒 Files selected for processing (82)
test/infra/infra-dbdeployer-mysql90-gr/.envtest/infra/infra-dbdeployer-mysql90-gr/bin/docker-mysql-post.bashtest/infra/infra-dbdeployer-mysql90-gr/bin/docker-proxy-post.bashtest/infra/infra-dbdeployer-mysql90-gr/conf/proxysql/infra-config.sqltest/infra/infra-dbdeployer-mysql90-gr/docker-compose-destroy.bashtest/infra/infra-dbdeployer-mysql90-gr/docker-compose-init.bashtest/infra/infra-dbdeployer-mysql90-gr/docker-compose.ymltest/infra/infra-dbdeployer-mysql90-gr/docker/Dockerfiletest/infra/infra-dbdeployer-mysql90-gr/docker/build.shtest/infra/infra-dbdeployer-mysql90-gr/docker/entrypoint.shtest/infra/infra-dbdeployer-mysql90/.envtest/infra/infra-dbdeployer-mysql90/bin/docker-mysql-post.bashtest/infra/infra-dbdeployer-mysql90/bin/docker-proxy-post.bashtest/infra/infra-dbdeployer-mysql90/conf/proxysql/infra-config.sqltest/infra/infra-dbdeployer-mysql90/docker-compose-destroy.bashtest/infra/infra-dbdeployer-mysql90/docker-compose-init.bashtest/infra/infra-dbdeployer-mysql90/docker-compose.ymltest/infra/infra-dbdeployer-mysql90/docker/Dockerfiletest/infra/infra-dbdeployer-mysql90/docker/build.shtest/infra/infra-dbdeployer-mysql90/docker/entrypoint.shtest/infra/infra-dbdeployer-mysql93-gr/.envtest/infra/infra-dbdeployer-mysql93-gr/bin/docker-mysql-post.bashtest/infra/infra-dbdeployer-mysql93-gr/bin/docker-proxy-post.bashtest/infra/infra-dbdeployer-mysql93-gr/conf/proxysql/infra-config.sqltest/infra/infra-dbdeployer-mysql93-gr/docker-compose-destroy.bashtest/infra/infra-dbdeployer-mysql93-gr/docker-compose-init.bashtest/infra/infra-dbdeployer-mysql93-gr/docker-compose.ymltest/infra/infra-dbdeployer-mysql93-gr/docker/Dockerfiletest/infra/infra-dbdeployer-mysql93-gr/docker/build.shtest/infra/infra-dbdeployer-mysql93-gr/docker/entrypoint.shtest/infra/infra-dbdeployer-mysql93/.envtest/infra/infra-dbdeployer-mysql93/bin/docker-mysql-post.bashtest/infra/infra-dbdeployer-mysql93/bin/docker-proxy-post.bashtest/infra/infra-dbdeployer-mysql93/conf/proxysql/infra-config.sqltest/infra/infra-dbdeployer-mysql93/docker-compose-destroy.bashtest/infra/infra-dbdeployer-mysql93/docker-compose-init.bashtest/infra/infra-dbdeployer-mysql93/docker-compose.ymltest/infra/infra-dbdeployer-mysql93/docker/Dockerfiletest/infra/infra-dbdeployer-mysql93/docker/build.shtest/infra/infra-dbdeployer-mysql93/docker/entrypoint.shtest/infra/infra-dbdeployer-mysql95-gr/.envtest/infra/infra-dbdeployer-mysql95-gr/bin/docker-mysql-post.bashtest/infra/infra-dbdeployer-mysql95-gr/bin/docker-proxy-post.bashtest/infra/infra-dbdeployer-mysql95-gr/conf/proxysql/infra-config.sqltest/infra/infra-dbdeployer-mysql95-gr/docker-compose-destroy.bashtest/infra/infra-dbdeployer-mysql95-gr/docker-compose-init.bashtest/infra/infra-dbdeployer-mysql95-gr/docker-compose.ymltest/infra/infra-dbdeployer-mysql95-gr/docker/Dockerfiletest/infra/infra-dbdeployer-mysql95-gr/docker/build.shtest/infra/infra-dbdeployer-mysql95-gr/docker/entrypoint.shtest/infra/infra-dbdeployer-mysql95/.envtest/infra/infra-dbdeployer-mysql95/bin/docker-mysql-post.bashtest/infra/infra-dbdeployer-mysql95/bin/docker-proxy-post.bashtest/infra/infra-dbdeployer-mysql95/conf/proxysql/infra-config.sqltest/infra/infra-dbdeployer-mysql95/docker-compose-destroy.bashtest/infra/infra-dbdeployer-mysql95/docker-compose-init.bashtest/infra/infra-dbdeployer-mysql95/docker-compose.ymltest/infra/infra-dbdeployer-mysql95/docker/Dockerfiletest/infra/infra-dbdeployer-mysql95/docker/build.shtest/infra/infra-dbdeployer-mysql95/docker/entrypoint.shtest/tap/groups/groups.jsontest/tap/groups/mysql90-gr/env.shtest/tap/groups/mysql90-gr/infras.lsttest/tap/groups/mysql90-gr/pre-proxysql.bashtest/tap/groups/mysql90/env.shtest/tap/groups/mysql90/infras.lsttest/tap/groups/mysql90/pre-proxysql.bashtest/tap/groups/mysql90/setup-infras.bashtest/tap/groups/mysql93-gr/env.shtest/tap/groups/mysql93-gr/infras.lsttest/tap/groups/mysql93-gr/pre-proxysql.bashtest/tap/groups/mysql93/env.shtest/tap/groups/mysql93/infras.lsttest/tap/groups/mysql93/pre-proxysql.bashtest/tap/groups/mysql93/setup-infras.bashtest/tap/groups/mysql95-gr/env.shtest/tap/groups/mysql95-gr/infras.lsttest/tap/groups/mysql95-gr/pre-proxysql.bashtest/tap/groups/mysql95/env.shtest/tap/groups/mysql95/infras.lsttest/tap/groups/mysql95/pre-proxysql.bashtest/tap/groups/mysql95/setup-infras.bash
✅ Files skipped from review due to trivial changes (22)
- test/tap/groups/mysql95/infras.lst
- test/tap/groups/mysql95-gr/infras.lst
- test/tap/groups/mysql90/infras.lst
- test/tap/groups/mysql93-gr/infras.lst
- test/infra/infra-dbdeployer-mysql95/docker/build.sh
- test/tap/groups/mysql93/infras.lst
- test/infra/infra-dbdeployer-mysql90-gr/docker/build.sh
- test/tap/groups/mysql90-gr/infras.lst
- test/tap/groups/mysql95/pre-proxysql.bash
- test/infra/infra-dbdeployer-mysql90/docker/build.sh
- test/infra/infra-dbdeployer-mysql93/docker/build.sh
- test/infra/infra-dbdeployer-mysql93-gr/docker/build.sh
- test/infra/infra-dbdeployer-mysql95-gr/docker/build.sh
- test/tap/groups/mysql95-gr/env.sh
- test/tap/groups/mysql93-gr/env.sh
- test/infra/infra-dbdeployer-mysql90/docker-compose.yml
- test/infra/infra-dbdeployer-mysql95-gr/docker-compose.yml
- test/tap/groups/mysql90/pre-proxysql.bash
- test/tap/groups/mysql90-gr/env.sh
- test/infra/infra-dbdeployer-mysql93-gr/docker-compose.yml
- test/infra/infra-dbdeployer-mysql95/docker-compose.yml
- test/tap/groups/mysql93/pre-proxysql.bash
| # RELIABLY CAPTURE INFRA_ID FROM ENVIRONMENT OR DIRECTORY NAME | ||
| if [ -z "${INFRA_ID}" ]; then | ||
| export INFRA_ID=$(basename $(dirname $(pwd)) | sed 's/infra-//; s/docker-//') | ||
| fi | ||
| # Final safety: if INFRA_ID is still empty or ".", use a default | ||
| if [ -z "${INFRA_ID}" ] || [ "${INFRA_ID}" = "." ]; then | ||
| export INFRA_ID="dev-$USER" | ||
| fi | ||
|
|
||
| # Derive Workspace relative to script | ||
| SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" | ||
| REPO_ROOT="$(cd "${SCRIPT_DIR}/../../.." && pwd)" | ||
| export WORKSPACE="${REPO_ROOT}" |
There was a problem hiding this comment.
Derive INFRA_ID from the script path, not the caller's cwd.
Line 4 uses dirname $(pwd), so running this script from the repo root or from the infra directory itself resolves the wrong name and silently falls back to dev-$USER. That changes ROOT_PASSWORD, COMPOSE_PROJECT, and backend network names for the whole stack.
🧰 Tools
🪛 Shellcheck (0.11.0)
[warning] 4-4: Declare and assign separately to avoid masking return values.
(SC2155)
[warning] 4-4: Quote this to prevent word splitting.
(SC2046)
[warning] 4-4: Quote this to prevent word splitting.
(SC2046)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/infra/infra-dbdeployer-mysql90-gr/docker-compose-init.bash` around lines
2 - 14, INFRA_ID is being derived from the caller's cwd (basename $(dirname
$(pwd))) which is wrong; compute SCRIPT_DIR first and derive INFRA_ID from the
script path (use dirname of SCRIPT_DIR) or move the
SCRIPT_DIR/SCRIPT_DIR-derived REPO_ROOT logic above the INFRA_ID block, then set
INFRA_ID with basename "$(dirname "$SCRIPT_DIR")" (or equivalent using dirname
"${SCRIPT_DIR}") so INFRA_ID is stable and based on the script location; keep
the existing fallback to "dev-$USER" unchanged.
| # Docker Compose version helper - prefer plugin (v2) | ||
| COMPOSE_CMD="docker compose" | ||
| if ! $COMPOSE_CMD version &>/dev/null; then | ||
| COMPOSE_CMD="docker-compose" | ||
| if ! $COMPOSE_CMD version &>/dev/null; then | ||
| echo "ERROR: Neither 'docker compose' nor 'docker-compose' found!" | ||
| exit 1 | ||
| fi | ||
| fi |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
sed -n '36,44p;129,145p' test/infra/infra-dbdeployer-mysql90-gr/docker-compose-init.bashRepository: sysown/proxysql
Length of output: 868
🏁 Script executed:
# Find docker-compose files in the test directory structure
find test/infra/infra-dbdeployer-mysql90-gr -name "docker-compose*" -type fRepository: sysown/proxysql
Length of output: 247
🏁 Script executed:
# Check the content of the docker-compose file if it exists
cat test/infra/infra-dbdeployer-mysql90-gr/docker-compose.yml 2>/dev/null || echo "File not found"Repository: sysown/proxysql
Length of output: 506
🏁 Script executed:
# Search for references to container naming in the repository to understand patterns
rg "COMPOSE_PROJECT" test/infra/infra-dbdeployer-mysql90-gr/ -A 2 -B 2Repository: sysown/proxysql
Length of output: 5797
Resolve the dbdeployer container name dynamically instead of hardcoding.
Line 130 hardcodes the container name as ${COMPOSE_PROJECT}-dbdeployer1-1, which creates a maintenance burden. While the docker-compose.yml explicitly sets this same value, hardcoding it in the bash script means the name must be kept in sync between two places. If the service name or container_name in the compose file changes, the hardcoded value becomes stale.
Instead, resolve the container using docker compose ps:
CONTAINER=$($COMPOSE_CMD -p "${COMPOSE_PROJECT}" ps -q dbdeployer1)This approach uses the compose command already validated in lines 36-44 to dynamically discover the actual container, ensuring consistency with the compose configuration.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/infra/infra-dbdeployer-mysql90-gr/docker-compose-init.bash` around lines
36 - 44, The script currently hardcodes the dbdeployer container name
(`${COMPOSE_PROJECT}-dbdeployer1-1`), which can drift from docker-compose;
instead use the already-detected COMPOSE_CMD and COMPOSE_PROJECT to discover the
container ID dynamically (e.g., run `docker compose ps -q dbdeployer1` via
COMPOSE_CMD) and assign it to a CONTAINER variable, then use that CONTAINER
variable wherever the hardcoded name was used; update references in the script
that used `${COMPOSE_PROJECT}-dbdeployer1-1` to use the resolved CONTAINER.
| RUN curl -fsSL "https://github.com/ProxySQL/dbdeployer/releases/download/v${DBDEPLOYER_VERSION}/dbdeployer-${DBDEPLOYER_VERSION}.linux_amd64.tar.gz" \ | ||
| | tar -xz -C /usr/local/bin/ \ | ||
| && chmod +x /usr/local/bin/dbdeployer |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, verify the file exists and examine its content
find . -path "*test/infra/infra-dbdeployer-mysql90-gr/docker/Dockerfile" -type fRepository: sysown/proxysql
Length of output: 117
🏁 Script executed:
# Search for the Dockerfile and read it
fd -t f "Dockerfile" | grep -i dbdeployerRepository: sysown/proxysql
Length of output: 734
🏁 Script executed:
# List files in test/infra directory to understand structure
ls -la test/infra/ 2>/dev/null | head -20Repository: sysown/proxysql
Length of output: 1396
🏁 Script executed:
# Read the target Dockerfile
cat -n test/infra/infra-dbdeployer-mysql90-gr/docker/DockerfileRepository: sysown/proxysql
Length of output: 1561
🏁 Script executed:
# Check if there are any project conventions documented for Dockerfiles
find . -name "*.md" -type f | xargs grep -l "Dockerfile\|docker\|artifact\|integrity\|checksum" 2>/dev/null | head -10Repository: sysown/proxysql
Length of output: 320
🏁 Script executed:
# Check if there are patterns of artifact verification in other Dockerfiles
grep -r "sha256sum" test/infra/ --include="Dockerfile" 2>/dev/nullRepository: sysown/proxysql
Length of output: 41
🏁 Script executed:
# Check if there are any other patterns for verifying downloads in Dockerfiles
grep -r "curl.*tar\|wget.*tar" test/infra/ --include="Dockerfile" -A 2 2>/dev/null | head -40Repository: sysown/proxysql
Length of output: 4145
🏁 Script executed:
# Check if there are project conventions or guidelines on security
find . -name "*.md" -type f | xargs grep -l "security\|convention" 2>/dev/nullRepository: sysown/proxysql
Length of output: 1278
🏁 Script executed:
# Verify that ca-certificates is indeed included (needed for HTTPS verification)
grep -n "ca-certificates" test/infra/infra-dbdeployer-mysql90-gr/docker/DockerfileRepository: sysown/proxysql
Length of output: 83
🏁 Script executed:
# Verify HTTPS certificate validation is in place by checking curl defaults
curl --help 2>/dev/null | grep -i "cert\|verify" | head -5Repository: sysown/proxysql
Length of output: 41
🏁 Script executed:
# Check if there are any GitHub release artifact files with checksums available
# This would tell us if checksum validation is even feasible for this artifact
web_search "dbdeployer 2.2.1 github release sha256"Repository: sysown/proxysql
Length of output: 109
🌐 Web query:
dbdeployer 2.2.1 github release checksums sha256
💡 Result:
No dbdeployer 2.2.1 release exists on GitHub. The primary dbdeployer repository (datacharmer/dbdeployer) is archived since Oct 2023, with latest release v1.73.0 (Jul 2023). No version 2.x releases found. A different project (covermymeds/dbdeployer) exists but latest is 1.5.10 (2021), not 2.2.1. No SHA256 checksums available for requested version.
Citations:
- 1: https://github.com/datacharmer/dbdeployer/releases
- 2: https://github.com/datacharmer/dbdeployer
- 3: https://github.com/covermymeds/dbdeployer
- 4: https://github.com/datacharmer/dbdeployer/releases/latest
- 5: https://linkedin.com/in/cj-estel-21383614
- 6: https://github.com/datacharmer/dbdeployer/tags
🏁 Script executed:
# Check the project conventions document
cat -n doc/agents/project-conventions.md | head -100Repository: sysown/proxysql
Length of output: 4500
🏁 Script executed:
# Check if ProxySQL has a fork of dbdeployer
git ls-remote --heads https://github.com/ProxySQL/dbdeployer 2>/dev/null | head -10Repository: sysown/proxysql
Length of output: 791
🏁 Script executed:
# Also check if there are any release artifacts or documentation about this custom version
find . -name "*dbdeployer*" -type f | grep -v "\.git\|node_modules\|dist" | head -20Repository: sysown/proxysql
Length of output: 193
🏁 Script executed:
# Check ProxySQL's custom dbdeployer fork for version 2.2.1
curl -s https://api.github.com/repos/ProxySQL/dbdeployer/releases/tags/v2.2.1 | head -50Repository: sysown/proxysql
Length of output: 338
🏁 Script executed:
# Check the checksums-and-init-provider branch to see if it addresses this issue
git show fix/checksums-and-init-provider:test/infra/infra-dbdeployer-mysql90-gr/docker/Dockerfile 2>/dev/null | head -30Repository: sysown/proxysql
Length of output: 41
🏁 Script executed:
# Also check current branch for any recent changes to this file
git log -1 --oneline test/infra/infra-dbdeployer-mysql90-gr/docker/DockerfileRepository: sysown/proxysql
Length of output: 144
Consider integrity verification for dbdeployer artifact downloads.
Lines 18-20 pipe curl directly into tar without checksum validation. While HTTPS certificate validation via ca-certificates (line 14) protects against network interception, this approach lacks additional integrity guarantees against repository compromise or artifact tampering—a recognized supply-chain security best practice.
This pattern is systematic across all dbdeployer Dockerfiles (9+ variants: mariadb10, mysql57, mysql84, mysql90, mysql93, mysql95, and their -binlog/-gr variants).
Before applying a fix: Verify if SHA256 checksums are published for the ProxySQL dbdeployer v2.2.1 fork (they don't exist on the archived upstream). If available, add download-and-verify pattern; if not, consider signing a tarball or documenting the TLS reliance as an accepted risk for CI infrastructure.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/infra/infra-dbdeployer-mysql90-gr/docker/Dockerfile` around lines 18 -
20, The curl|tar pipeline that downloads dbdeployer using the DBDEPLOYER_VERSION
env var should include integrity verification: first check whether a published
SHA256 (or GPG signature) exists for the specific dbdeployer release; if a
SHA256 is available, download the checksum alongside the tarball and verify it
(e.g., via sha256sum -c) before extracting to /usr/local/bin/dbdeployer, or if a
signed artifact exists verify via gpg; if no checksum/signature is published,
add a short documented justification in CI/Docker build docs that TLS
(ca-certificates) is relied upon and note the accepted risk for these dbdeployer
artifacts.
| for PORT in 3307 3308; do | ||
| echo -n "Checking replication on port ${PORT}..." | ||
| REPLICA_STATUS=$(docker exec "${CONTAINER}" mysql -h127.0.0.1 -P${PORT} -uroot -p"${ROOT_PASSWORD}" -e "SHOW REPLICA STATUS\G" 2>/dev/null) | ||
| IO_RUNNING=$(echo "${REPLICA_STATUS}" | grep "Replica_IO_Running:" | awk '{print $2}') | ||
| SQL_RUNNING=$(echo "${REPLICA_STATUS}" | grep "Replica_SQL_Running:" | awk '{print $2}') | ||
| if [ "${IO_RUNNING}" = "Yes" ] && [ "${SQL_RUNNING}" = "Yes" ]; then | ||
| echo " OK (IO: Yes, SQL: Yes)" | ||
| else | ||
| echo " WARNING (IO: ${IO_RUNNING}, SQL: ${SQL_RUNNING})" | ||
| fi |
There was a problem hiding this comment.
Fail the post-check when replication is unhealthy.
This loop only logs a warning when Replica_IO_Running or Replica_SQL_Running is not Yes, so the infra can proceed with a broken async topology and surface as later test noise instead of an immediate setup failure.
Suggested fix
if [ "${IO_RUNNING}" = "Yes" ] && [ "${SQL_RUNNING}" = "Yes" ]; then
echo " OK (IO: Yes, SQL: Yes)"
else
- echo " WARNING (IO: ${IO_RUNNING}, SQL: ${SQL_RUNNING})"
+ echo " FAILED (IO: ${IO_RUNNING}, SQL: ${SQL_RUNNING})"
+ exit 1
fi
done📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| for PORT in 3307 3308; do | |
| echo -n "Checking replication on port ${PORT}..." | |
| REPLICA_STATUS=$(docker exec "${CONTAINER}" mysql -h127.0.0.1 -P${PORT} -uroot -p"${ROOT_PASSWORD}" -e "SHOW REPLICA STATUS\G" 2>/dev/null) | |
| IO_RUNNING=$(echo "${REPLICA_STATUS}" | grep "Replica_IO_Running:" | awk '{print $2}') | |
| SQL_RUNNING=$(echo "${REPLICA_STATUS}" | grep "Replica_SQL_Running:" | awk '{print $2}') | |
| if [ "${IO_RUNNING}" = "Yes" ] && [ "${SQL_RUNNING}" = "Yes" ]; then | |
| echo " OK (IO: Yes, SQL: Yes)" | |
| else | |
| echo " WARNING (IO: ${IO_RUNNING}, SQL: ${SQL_RUNNING})" | |
| fi | |
| for PORT in 3307 3308; do | |
| echo -n "Checking replication on port ${PORT}..." | |
| REPLICA_STATUS=$(docker exec "${CONTAINER}" mysql -h127.0.0.1 -P${PORT} -uroot -p"${ROOT_PASSWORD}" -e "SHOW REPLICA STATUS\G" 2>/dev/null) | |
| IO_RUNNING=$(echo "${REPLICA_STATUS}" | grep "Replica_IO_Running:" | awk '{print $2}') | |
| SQL_RUNNING=$(echo "${REPLICA_STATUS}" | grep "Replica_SQL_Running:" | awk '{print $2}') | |
| if [ "${IO_RUNNING}" = "Yes" ] && [ "${SQL_RUNNING}" = "Yes" ]; then | |
| echo " OK (IO: Yes, SQL: Yes)" | |
| else | |
| echo " FAILED (IO: ${IO_RUNNING}, SQL: ${SQL_RUNNING})" | |
| exit 1 | |
| fi | |
| done |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/infra/infra-dbdeployer-mysql90/bin/docker-mysql-post.bash` around lines
35 - 44, The loop that checks replication (variables PORT, REPLICA_STATUS,
IO_RUNNING, SQL_RUNNING, using docker exec against CONTAINER with ROOT_PASSWORD)
currently only prints a warning for unhealthy replicas; modify it so that when
either IO_RUNNING or SQL_RUNNING is not "Yes" you print a clear error message
including the port and statuses and then fail the script (exit with non‑zero,
e.g. exit 1) so the post-check aborts on unhealthy replication; alternatively
accumulate failures in a flag and call exit 1 after the loop if any port failed.
| docker exec -i "${PROXY_CONTAINER}" mysql -uadmin -padmin -h127.0.0.1 -P6032 <<SQL | ||
| $(eval "echo \"$(cat ./conf/proxysql/infra-config.sql)\"") |
There was a problem hiding this comment.
Use a script-relative path for infra-config.sql here as well.
Line 11 still reads ./conf/proxysql/infra-config.sql from the caller's cwd. If the harness doesn't cd into this infra directory first, the ProxySQL bootstrap silently stops at the file lookup.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/infra/infra-dbdeployer-mysql90/bin/docker-proxy-post.bash` around lines
10 - 11, The script uses a relative path "./conf/proxysql/infra-config.sql"
which depends on the caller's CWD; fix docker-proxy-post.bash to compute the
script directory (e.g., via DIR="$(cd "$(dirname "${BASH_SOURCE[0]:-$0}")" &&
pwd)") and replace "./conf/proxysql/infra-config.sql" with a script-relative
path like "$DIR/conf/proxysql/infra-config.sql" when constructing the heredoc
passed to docker exec (the command that uses ${PROXY_CONTAINER} and the eval/cat
invocation).
| # RELIABLY CAPTURE INFRA_ID FROM ENVIRONMENT OR DIRECTORY NAME | ||
| if [ -z "${INFRA_ID}" ]; then | ||
| export INFRA_ID=$(basename $(dirname $(pwd)) | sed 's/infra-//; s/docker-//') | ||
| fi | ||
| # Final safety: if INFRA_ID is still empty or ".", use a default | ||
| if [ -z "${INFRA_ID}" ] || [ "${INFRA_ID}" = "." ]; then | ||
| export INFRA_ID="dev-$USER" | ||
| fi | ||
|
|
||
| # Derive Workspace relative to script | ||
| SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" | ||
| REPO_ROOT="$(cd "${SCRIPT_DIR}/../../.." && pwd)" | ||
| export WORKSPACE="${REPO_ROOT}" |
There was a problem hiding this comment.
Derive INFRA_ID from the script path, not the caller's cwd.
Line 4 uses dirname $(pwd), so running this script from the repo root or from the infra directory itself resolves the wrong name and silently falls back to dev-$USER. That changes ROOT_PASSWORD, COMPOSE_PROJECT, and backend network names for the whole stack.
🧰 Tools
🪛 Shellcheck (0.11.0)
[warning] 4-4: Declare and assign separately to avoid masking return values.
(SC2155)
[warning] 4-4: Quote this to prevent word splitting.
(SC2046)
[warning] 4-4: Quote this to prevent word splitting.
(SC2046)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/infra/infra-dbdeployer-mysql95/docker-compose-init.bash` around lines 2
- 14, The INFRA_ID derivation currently uses dirname $(pwd) which reflects the
caller's cwd; change it to derive from the script path by using SCRIPT_DIR (or
its parent directory) instead—replace the line setting INFRA_ID from basename
$(dirname $(pwd)) with a basename of the parent dir of SCRIPT_DIR (then pipe
through sed 's/infra-//; s/docker-//') so INFRA_ID is based on the script
location; keep the existing fallback check that sets INFRA_ID="dev-$USER" and
leave SCRIPT_DIR, REPO_ROOT, and WORKSPACE logic unchanged.
| # Wait for all 3 nodes to accept connections | ||
| for i in 0 1 2; do | ||
| PORT="${NODE_PORTS[$i]}" | ||
| NAME="${NODE_NAMES[$i]}" | ||
| echo -n "Waiting for ${NAME} on port ${PORT}..." | ||
| MAX_WAIT=60 | ||
| COUNT=0 | ||
| while ! ${MYSQL_CMD} -P${PORT} -e "SELECT 1" >/dev/null 2>&1; do | ||
| if [ $COUNT -ge $MAX_WAIT ]; then | ||
| echo " TIMEOUT" | ||
| exit 1 | ||
| fi | ||
| echo -n "." | ||
| sleep 1 | ||
| COUNT=$((COUNT + 1)) | ||
| done | ||
| echo " OK" | ||
| done |
There was a problem hiding this comment.
Don't mark the sandbox ready before replication is healthy.
This only waits for ports to accept connections, then creates /tmp/dbdeployer_ready without checking replica IO/SQL state on 3307/3308. The harness can start tests against a topology that is reachable but not actually replicating yet.
Also applies to: 137-138
🧰 Tools
🪛 Shellcheck (0.11.0)
[info] 61-61: Double quote to prevent globbing and word splitting.
(SC2086)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/infra/infra-dbdeployer-mysql95/docker/entrypoint.sh` around lines 54 -
71, The script currently only waits for sockets to accept connections (loop over
NODE_PORTS/NODE_NAMES using MYSQL_CMD) but then creates /tmp/dbdeployer_ready
before checking replication; update the entrypoint so that after the existing
port-wait loop you add a second health check for the replica nodes (ports from
NODE_PORTS for nodes 1 and 2) that repeatedly runs MYSQL_CMD -P${PORT} -e "SHOW
SLAVE STATUS\G" (MySQL5.7) and parses for Slave_IO_Running: Yes and
Slave_SQL_Running: Yes (or the equivalent replica fields) with a similar
MAX_WAIT/COUNT timeout and retries; only create /tmp/dbdeployer_ready once both
replicas report IO and SQL running, and fail the script (exit 1) on timeout,
keeping references to MYSQL_CMD, NODE_PORTS, NODE_NAMES, and
/tmp/dbdeployer_ready so the change is easy to locate.
| if [ -d "${WORKSPACE}/test/tap/tests/reg_test_3223_scripts" ]; then | ||
| echo ">>> [mysql90/setup-infras] Copying RESTAPI test scripts to ProxySQL data directory..." | ||
| mkdir -p "${PROXY_DATA_DIR}/reg_test_3223_scripts" | ||
| cp -r "${WORKSPACE}/test/tap/tests/reg_test_3223_scripts/"* "${PROXY_DATA_DIR}/reg_test_3223_scripts/" | ||
| # Add execute permissions to all scripts EXCEPT script_no_permissions (which tests EACCES) |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Find and read the setup-infras.bash file for mysql90
fd -t f "setup-infras.bash" test/tap/groups/Repository: sysown/proxysql
Length of output: 349
🏁 Script executed:
# Read the full mysql90 setup-infras.bash file with line numbers
cat -n test/tap/groups/mysql90/setup-infras.bashRepository: sysown/proxysql
Length of output: 1685
🏁 Script executed:
# Check mysql93 and mysql95 setup scripts for comparison
cat -n test/tap/groups/mysql93/setup-infras.bashRepository: sysown/proxysql
Length of output: 1685
🏁 Script executed:
# Also check mysql95
fd -t f "setup-infras.bash" test/tap/groups/ | xargs -I {} sh -c 'echo "=== {} ===" && head -30 {}'Repository: sysown/proxysql
Length of output: 9265
🏁 Script executed:
# Check if the directory exists and list its contents
find test/tap/tests -name "reg_test_3223_scripts" -type dRepository: sysown/proxysql
Length of output: 95
🏁 Script executed:
# List all files in that directory if it exists
if [ -d "test/tap/tests/reg_test_3223_scripts" ]; then
ls -la test/tap/tests/reg_test_3223_scripts/
else
echo "Directory does not exist"
fiRepository: sysown/proxysql
Length of output: 1133
Use copy pattern that tolerates empty directories.
Line 24 uses * glob expansion, which can fail and stop execution with set -e if the directory becomes empty. While currently the directory contains scripts, this pattern is fragile and should be replaced with a more robust approach.
🛠️ Suggested fix
- cp -r "${WORKSPACE}/test/tap/tests/reg_test_3223_scripts/"* "${PROXY_DATA_DIR}/reg_test_3223_scripts/"
+ cp -a "${WORKSPACE}/test/tap/tests/reg_test_3223_scripts/." "${PROXY_DATA_DIR}/reg_test_3223_scripts/"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/tap/groups/mysql90/setup-infras.bash` around lines 21 - 25, The cp
command uses a '*' glob that will fail under set -e if the source directory is
empty; update the copy to tolerate empty directories by replacing the glob-based
copy of WORKSPACE/.../reg_test_3223_scripts/* with a directory-content copy
(e.g., copy from the reg_test_3223_scripts directory itself using the "copy
contents" form or switch to rsync -a) into PROXY_DATA_DIR/reg_test_3223_scripts
so the operation succeeds even when the source has no files; keep the existing
mkdir -p for PROXY_DATA_DIR and preserve permissions handling for
script_no_permissions.
| if [ -d "${WORKSPACE}/test/tap/tests/reg_test_3223_scripts" ]; then | ||
| echo ">>> [mysql93/setup-infras] Copying RESTAPI test scripts to ProxySQL data directory..." | ||
| mkdir -p "${PROXY_DATA_DIR}/reg_test_3223_scripts" | ||
| cp -r "${WORKSPACE}/test/tap/tests/reg_test_3223_scripts/"* "${PROXY_DATA_DIR}/reg_test_3223_scripts/" | ||
| # Add execute permissions to all scripts EXCEPT script_no_permissions (which tests EACCES) |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, read the actual file to verify the content and check for set -e
cat -n test/tap/groups/mysql93/setup-infras.bash | head -30Repository: sysown/proxysql
Length of output: 1621
🏁 Script executed:
# Check if set -e is used in the script
head -10 test/tap/groups/mysql93/setup-infras.bashRepository: sysown/proxysql
Length of output: 409
🏁 Script executed:
# Search for similar copy patterns in mysql90 and mysql95 setup scripts
find . -path "*/groups/mysql90/setup-infras.bash" -o -path "*/groups/mysql95/setup-infras.bash" | xargs -I {} sh -c 'echo "=== {} ===" && head -30 {}'Repository: sysown/proxysql
Length of output: 2868
🏁 Script executed:
# Check if those files also have the reg_test_3223_scripts pattern
grep -r "reg_test_3223_scripts" test/tap/groups/Repository: sysown/proxysql
Length of output: 3447
Fix empty-directory handling in copy operations under set -e.
Line 24 can fail when the source directory exists but is empty—the unmatched glob * causes cp to receive a literal pattern that doesn't exist, aborting the script. The directory existence check doesn't guard against this case. Use the dot-copy form to safely handle both populated and empty directories.
This same pattern appears in test/tap/groups/legacy/setup-infras.bash, test/tap/groups/mysql84/setup-infras.bash, test/tap/groups/mysql90/setup-infras.bash, and test/tap/groups/mysql95/setup-infras.bash and should be fixed identically in all files.
Suggested fix
- cp -r "${WORKSPACE}/test/tap/tests/reg_test_3223_scripts/"* "${PROXY_DATA_DIR}/reg_test_3223_scripts/"
+ cp -a "${WORKSPACE}/test/tap/tests/reg_test_3223_scripts/." "${PROXY_DATA_DIR}/reg_test_3223_scripts/"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/tap/groups/mysql93/setup-infras.bash` around lines 21 - 25, The cp
command that uses the glob "*" can fail under set -e when the source directory
exists but is empty; update the copy in the mysql93/setup-infras.bash to use the
dot-copy form (copy the directory contents with "/." — e.g., cp -r
"${WORKSPACE}/test/tap/tests/reg_test_3223_scripts/."
"${PROXY_DATA_DIR}/reg_test_3223_scripts/") so empty directories are handled
safely, and apply the identical change to the same cp occurrences in
legacy/setup-infras.bash, mysql84/setup-infras.bash, mysql90/setup-infras.bash,
and mysql95/setup-infras.bash (referencing the cp invocation that uses
"${WORKSPACE}/test/tap/tests/reg_test_3223_scripts" and the target
"${PROXY_DATA_DIR}/reg_test_3223_scripts").
| if [ -d "${WORKSPACE}/test/tap/tests/reg_test_3223_scripts" ]; then | ||
| echo ">>> [mysql95/setup-infras] Copying RESTAPI test scripts to ProxySQL data directory..." | ||
| mkdir -p "${PROXY_DATA_DIR}/reg_test_3223_scripts" | ||
| cp -r "${WORKSPACE}/test/tap/tests/reg_test_3223_scripts/"* "${PROXY_DATA_DIR}/reg_test_3223_scripts/" | ||
| # Add execute permissions to all scripts EXCEPT script_no_permissions (which tests EACCES) |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Check the script header and full context
cat -n test/tap/groups/mysql95/setup-infras.bash | head -40Repository: sysown/proxysql
Length of output: 1685
🏁 Script executed:
# Check if set -e is enabled
rg -n "set -e|set -o errexit" test/tap/groups/mysql95/setup-infras.bashRepository: sysown/proxysql
Length of output: 67
🏁 Script executed:
# Verify the source directory structure
fd -t d "reg_test_3223_scripts" test/tap/tests/Repository: sysown/proxysql
Length of output: 96
🏁 Script executed:
# Check mysql90 and mysql93 setup files for similar patterns
ls -la test/tap/groups/ | grep -E "mysql9[03]"Repository: sysown/proxysql
Length of output: 300
🏁 Script executed:
# Look for similar glob-based copy patterns in mysql90/mysql93
rg -n 'cp.*\*' test/tap/groups/mysql90/ test/tap/groups/mysql93/ 2>/dev/null | head -20Repository: sysown/proxysql
Length of output: 362
🏁 Script executed:
# Check what's inside the reg_test_3223_scripts directory
find test/tap/tests/reg_test_3223_scripts -type f -o -type d | head -20Repository: sysown/proxysql
Length of output: 887
🏁 Script executed:
# Verify the behavior difference: glob expansion vs dot notation
# Test glob behavior when directory is not empty
python3 << 'EOF'
import os
import subprocess
# Check if the directory has content
scripts_dir = "test/tap/tests/reg_test_3223_scripts"
contents = os.listdir(scripts_dir)
print(f"Directory exists: {os.path.isdir(scripts_dir)}")
print(f"Contents count: {len(contents)}")
print(f"Contents: {contents}")
# Test glob expansion behavior
glob_pattern = os.path.join(scripts_dir, "*")
import glob
expanded = glob.glob(glob_pattern)
print(f"\nGlob pattern '{glob_pattern}' expands to {len(expanded)} items")
if expanded:
print(f"First few items: {expanded[:3]}")
EOFRepository: sysown/proxysql
Length of output: 741
🏁 Script executed:
# Check if there are similar issues in mysql90-gr and mysql93-gr
ls -la test/tap/groups/mysql90-gr/ test/tap/groups/mysql93-gr/Repository: sysown/proxysql
Length of output: 717
Avoid glob-fragile copy in setup hook.
Line 24 uses a glob pattern that will fail if the source directory becomes empty, causing the script to terminate due to set -e. The conditional check on line 21 only verifies directory existence, not content. Use cp -a with dot notation instead to handle all cases robustly.
🛠️ Suggested fix
- cp -r "${WORKSPACE}/test/tap/tests/reg_test_3223_scripts/"* "${PROXY_DATA_DIR}/reg_test_3223_scripts/"
+ cp -a "${WORKSPACE}/test/tap/tests/reg_test_3223_scripts/." "${PROXY_DATA_DIR}/reg_test_3223_scripts/"Note: The same pattern appears in mysql90/setup-infras.bash and mysql93/setup-infras.bash (line 24 in both files).
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| if [ -d "${WORKSPACE}/test/tap/tests/reg_test_3223_scripts" ]; then | |
| echo ">>> [mysql95/setup-infras] Copying RESTAPI test scripts to ProxySQL data directory..." | |
| mkdir -p "${PROXY_DATA_DIR}/reg_test_3223_scripts" | |
| cp -r "${WORKSPACE}/test/tap/tests/reg_test_3223_scripts/"* "${PROXY_DATA_DIR}/reg_test_3223_scripts/" | |
| # Add execute permissions to all scripts EXCEPT script_no_permissions (which tests EACCES) | |
| if [ -d "${WORKSPACE}/test/tap/tests/reg_test_3223_scripts" ]; then | |
| echo ">>> [mysql95/setup-infras] Copying RESTAPI test scripts to ProxySQL data directory..." | |
| mkdir -p "${PROXY_DATA_DIR}/reg_test_3223_scripts" | |
| cp -a "${WORKSPACE}/test/tap/tests/reg_test_3223_scripts/." "${PROXY_DATA_DIR}/reg_test_3223_scripts/" | |
| # Add execute permissions to all scripts EXCEPT script_no_permissions (which tests EACCES) |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/tap/groups/mysql95/setup-infras.bash` around lines 21 - 25, The copy
uses a glob that fails when the source dir is empty; replace the fragile cp -r
"${WORKSPACE}/.../"* usage in the setup hook for reg_test_3223_scripts with a
robust dot-copy approach (use cp -a with the source directory’s dot notation)
and ensure the target dir (${PROXY_DATA_DIR}/reg_test_3223_scripts) is created
beforehand; apply the same fix to the corresponding copies in
mysql90/setup-infras.bash and mysql93/setup-infras.bash so the scripts won't
exit under set -e when the source is empty.
My earlier guess was wrong — I hadn't verified against dbdeployer's
actual remote catalog. The real x86_64 bundles use glibc2.17 (glibc2.28
is only shipped for aarch64). Confirmed via:
dbdeployer downloads list | grep mysql-9.[035]
...
mysql-9.0.1-linux-glibc2.17-x86_64.tar.xz
mysql-9.3.0-linux-glibc2.17-x86_64.tar.xz
mysql-9.5.0-linux-glibc2.17-x86_64.tar.xz
Smoke-tested both mysql90 and mysql90-gr images end-to-end:
- docker build succeeds
- entrypoint completes (3-node replication deployed, GR members all ONLINE)
- testuser authenticates successfully on all three ports via
caching_sha2_password (default plugin, since we dropped
mysql_native_password in the previous commit)
- GR user replication propagates to all secondaries
Every TAP test currently executed against mysql84-g[1-5] is now also
executed against the corresponding mysql95-g[1-5] group. Same 5-bucket
split, same assignment per bucket:
mysql84-g1: 78 → mysql95-g1: 78
mysql84-g2: 42 → mysql95-g2: 42
mysql84-g3: 40 → mysql95-g3: 40
mysql84-g4: 60 → mysql95-g4: 60
mysql84-g5: 5 → mysql95-g5: 5
total: 225 total: 225
Rationale: validates the full 8.4 test surface on MySQL 9.5, which is
the whole point of adding the 9.x infras — different MySQL major
versions catch different regressions (e.g., mysql_native_password
removal in 9.0). Group Replication variants (mysql*-gr-g*) are
intentionally out of scope for now.
Scripted via a simple walk over groups.json: for each entry containing
mysql84-gN, add mysql95-gN if missing, then re-sort. Verified:
- 209 new memberships added (225 target - 16 already existing from
the earlier mysql95-g1 seeding)
- check_groups.py reports 385/385 tests registered, no orphans
- per-bucket counts now match mysql84-g[1-5] exactly
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (3)
test/infra/infra-dbdeployer-mysql90-gr/docker/Dockerfile (1)
18-20:⚠️ Potential issue | 🟠 MajorAdd artifact integrity verification for the dbdeployer download.
This still streams a release artifact directly into
tarwithout checksum/signature verification. Since this was already flagged in earlier review rounds, please either add verification or explicitly document TLS-only trust as accepted CI risk.#!/bin/bash set -euo pipefail # Verify whether checksum/signature assets exist for the pinned dbdeployer release VER="2.2.1" API="https://api.github.com/repos/ProxySQL/dbdeployer/releases/tags/v${VER}" echo "Checking release metadata for v${VER}..." curl -fsSL "$API" | jq -r ' .tag_name as $tag | "tag=\($tag)", "assets:", (.assets[]?.name // "none") '🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql90-gr/docker/Dockerfile` around lines 18 - 20, The Dockerfile currently streams the dbdeployer tarball into tar without integrity checks; update the Dockerfile to fetch and verify the release checksum/signature for the artifact identified by DBDEPLOYER_VERSION and only extract to /usr/local/bin/dbdeployer after successful verification (e.g., download accompanying .sha256 or .asc from the release, verify with sha256sum or gpg, then tar -xz and chmod), referencing DBDEPLOYER_VERSION and /usr/local/bin/dbdeployer to locate the steps; if no checksum/signature is available for that release, add an explicit comment in the Dockerfile documenting that TLS-only trust for the GitHub release artifact is an acknowledged CI risk.test/infra/infra-dbdeployer-mysql93-gr/docker/Dockerfile (1)
18-20:⚠️ Potential issue | 🟠 MajorProtect dbdeployer installation with checksum verification.
Line 18 still uses
curl | tarwithout validation. Please verify the release artifact checksum before extraction.🔒 Suggested hardening patch
ARG DBDEPLOYER_VERSION=2.2.1 # Install dbdeployer -RUN curl -fsSL "https://github.com/ProxySQL/dbdeployer/releases/download/v${DBDEPLOYER_VERSION}/dbdeployer-${DBDEPLOYER_VERSION}.linux_amd64.tar.gz" \ - | tar -xz -C /usr/local/bin/ \ - && chmod +x /usr/local/bin/dbdeployer +RUN set -eux; \ + ASSET="dbdeployer-${DBDEPLOYER_VERSION}.linux_amd64.tar.gz"; \ + BASE_URL="https://github.com/ProxySQL/dbdeployer/releases/download/v${DBDEPLOYER_VERSION}"; \ + curl -fsSL -o "/tmp/${ASSET}" "${BASE_URL}/${ASSET}"; \ + curl -fsSL -o /tmp/checksums.txt "${BASE_URL}/checksums.txt"; \ + grep " ${ASSET}$" /tmp/checksums.txt | sha256sum -c -; \ + tar -xzf "/tmp/${ASSET}" -C /usr/local/bin/; \ + chmod +x /usr/local/bin/dbdeployer; \ + rm -f "/tmp/${ASSET}" /tmp/checksums.txt🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql93-gr/docker/Dockerfile` around lines 18 - 20, The Dockerfile currently streams the remote dbdeployer tarball directly into tar (the RUN command using DBDEPLOYER_VERSION), so add checksum verification: download the tarball and its accompanying checksum (e.g., .sha256 or .sha256sum for the same DBDEPLOYER_VERSION) into a temporary location, verify the archive with sha256sum (or openssl dgst) and only if verification succeeds, extract to /usr/local/bin/ and chmod +x /usr/local/bin/dbdeployer; reference DBDEPLOYER_VERSION and the /usr/local/bin/dbdeployer target when implementing the download, verification, extraction and cleanup steps.test/infra/infra-dbdeployer-mysql93/docker/Dockerfile (1)
18-20:⚠️ Potential issue | 🟠 MajorAdd checksum verification before extracting dbdeployer tarball.
Line 18 pipes a remote binary archive directly into
tarwith no integrity check. This is a supply-chain gap and should fail-fast on tampering/corruption.🔒 Suggested hardening patch
ARG DBDEPLOYER_VERSION=2.2.1 # Install dbdeployer -RUN curl -fsSL "https://github.com/ProxySQL/dbdeployer/releases/download/v${DBDEPLOYER_VERSION}/dbdeployer-${DBDEPLOYER_VERSION}.linux_amd64.tar.gz" \ - | tar -xz -C /usr/local/bin/ \ - && chmod +x /usr/local/bin/dbdeployer +RUN set -eux; \ + ASSET="dbdeployer-${DBDEPLOYER_VERSION}.linux_amd64.tar.gz"; \ + BASE_URL="https://github.com/ProxySQL/dbdeployer/releases/download/v${DBDEPLOYER_VERSION}"; \ + curl -fsSL -o "/tmp/${ASSET}" "${BASE_URL}/${ASSET}"; \ + curl -fsSL -o /tmp/checksums.txt "${BASE_URL}/checksums.txt"; \ + grep " ${ASSET}$" /tmp/checksums.txt | sha256sum -c -; \ + tar -xzf "/tmp/${ASSET}" -C /usr/local/bin/; \ + chmod +x /usr/local/bin/dbdeployer; \ + rm -f "/tmp/${ASSET}" /tmp/checksums.txt🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql93/docker/Dockerfile` around lines 18 - 20, The Dockerfile currently pipes the remote dbdeployer tarball directly into tar (using DBDEPLOYER_VERSION) which skips integrity checks; change the steps to first download the tarball and its checksum (for the matching v${DBDEPLOYER_VERSION} release) to temporary files, verify the checksum (e.g., with sha256sum -c or sha256sum --check) and abort on mismatch, and only after successful verification extract to /usr/local/bin/ (instead of piping into tar -xz -C) and set chmod +x on /usr/local/bin/dbdeployer; ensure the commands reference DBDEPLOYER_VERSION and fail the build if verification fails.
🧹 Nitpick comments (4)
test/infra/infra-dbdeployer-mysql90-gr/docker/Dockerfile (1)
1-38: Document the root-user exception or refactor to support non-root execution.The container runs as root with no
USERdirective. Hardcoded/root/paths in the Dockerfile and entrypoint.sh (/root/opt/mysql,/root/sandboxes) create tight coupling to root execution. For test infrastructure, document why root is required; otherwise, refactor to use a configurable base path (e.g., via environment variable) to support non-root users.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql90-gr/docker/Dockerfile` around lines 1 - 38, The Dockerfile and entrypoint.sh hardcode root-only paths (/root/opt/mysql, /root/sandboxes) and run as root with no USER directive; either document this root-only requirement in the Dockerfile comments and README, or refactor to support non-root execution by introducing a configurable base directory environment variable (e.g., BASE_DIR with default /root), update references in the Dockerfile (ENV PATH to use ${BASE_DIR}/opt/mysql) and entrypoint.sh to read BASE_DIR, and optionally add a USER creation/CHOWN flow or document why USER cannot be changed; look for symbols and files named Dockerfile, entrypoint.sh, PATH/ENV lines, dbdeployer download/install steps, and reserved-ports update to ensure all /root occurrences are replaced or parameterized.test/infra/infra-dbdeployer-mysql93-gr/docker/Dockerfile (1)
3-3: Centralize MySQL version to a single ARG.Line 24 and Line 31 both hardcode
9.3.0; using one ARG avoids future partial upgrades.♻️ Suggested refactor
ARG DBDEPLOYER_VERSION=2.2.1 +ARG MYSQL_VERSION=9.3.0 @@ -RUN mkdir -p /root/opt/mysql \ - && dbdeployer downloads get-unpack mysql-9.3.0-linux-glibc2.17-x86_64.tar.xz +RUN mkdir -p /root/opt/mysql \ + && dbdeployer downloads get-unpack mysql-${MYSQL_VERSION}-linux-glibc2.17-x86_64.tar.xz @@ -ENV PATH="/root/opt/mysql/9.3.0/bin:${PATH}" +ENV PATH="/root/opt/mysql/${MYSQL_VERSION}/bin:${PATH}"Also applies to: 23-24, 31-31
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql93-gr/docker/Dockerfile` at line 3, The Dockerfile currently hardcodes MySQL version "9.3.0" in multiple places; introduce a single ARG (e.g., MYSQL_VERSION or DBDEPLOYER_MYSQL_VERSION) at the top (like the existing ARG DBDEPLOYER_VERSION) and replace every hardcoded "9.3.0" occurrence with that ARG reference so both the base image and any other instructions use the same centralized version variable (update occurrences near where the Dockerfile uses the MySQL base image and any package/version installs).test/infra/infra-dbdeployer-mysql93/docker/Dockerfile (1)
3-3: Avoid hardcoding9.3.0in multiple places.The version is repeated in Line 24 and Line 31. Promote it to a single ARG to prevent drift when bumping versions.
♻️ Suggested refactor
ARG DBDEPLOYER_VERSION=2.2.1 +ARG MYSQL_VERSION=9.3.0 @@ -RUN mkdir -p /root/opt/mysql \ - && dbdeployer downloads get-unpack mysql-9.3.0-linux-glibc2.17-x86_64.tar.xz +RUN mkdir -p /root/opt/mysql \ + && dbdeployer downloads get-unpack mysql-${MYSQL_VERSION}-linux-glibc2.17-x86_64.tar.xz @@ -ENV PATH="/root/opt/mysql/9.3.0/bin:${PATH}" +ENV PATH="/root/opt/mysql/${MYSQL_VERSION}/bin:${PATH}"Also applies to: 23-24, 31-31
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql93/docker/Dockerfile` at line 3, The Dockerfile currently hardcodes the MySQL client/server/version string (e.g., "9.3.0") in multiple places; introduce a single ARG like MYSQL_VERSION and replace all literal "9.3.0" occurrences with that variable to avoid drift. Add ARG MYSQL_VERSION=<current-version> alongside ARG DBDEPLOYER_VERSION, then update the Dockerfile instructions that reference the version (the commands/lines that currently include "9.3.0") to use ${MYSQL_VERSION} so all references point to the single source of truth.test/infra/infra-dbdeployer-mysql95-gr/docker/Dockerfile (1)
1-38: A non-root USER is recommended, but requires refactoring hard-coded paths.The suggestion to run as non-root is sound from a security perspective. However, the current setup is tightly coupled to
/root/directories: the entrypoint.sh resolves MySQL versions from/root/opt/mysql/, sandboxes are created under/root/sandboxes/, and the PATH environment variable explicitly references/root/opt/mysql/9.5.0/bin. Simply addingUSERwould fail at runtime.To implement this properly, refactor to use a non-root-owned directory (e.g.,
/opt/mysql,/home/mysql, or a configurableDBDEPLOYER_HOME) and update all path references in entrypoint.sh, docker-mysql-post.bash, and environment variables accordingly.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql95-gr/docker/Dockerfile` around lines 1 - 38, The Dockerfile currently hard-codes /root paths preventing safe USER switching; change installation and runtime paths to a non-root location and make them configurable: introduce an ENV like DBDEPLOYER_HOME=/opt/dbdeployer (or /opt/mysql), update the dbdeployer download/unpack target and the mkdir target from /root/opt/mysql and /root/sandboxes to use ${DBDEPLOYER_HOME} and a sandboxes subdir, update ENV PATH to include ${DBDEPLOYER_HOME}/9.5.0/bin, and refactor entrypoint.sh and docker-mysql-post.bash to read DBDEPLOYER_HOME (or derive from $DBDEPLOYER_HOME) instead of /root paths so you can safely add a USER instruction and run as non-root.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@test/infra/infra-dbdeployer-mysql95/docker/Dockerfile`:
- Around line 1-38: The proposed switch-to-nonroot change breaks hardcoded /root
paths used by entrypoint.sh and docker-mysql-post.bash and dbdeployer’s download
location; update entrypoint.sh and docker-mysql-post.bash to reference ${HOME}
or /home/dbd (e.g., replace /root/opt/mysql and /root/sandboxes with
${HOME}/opt/mysql and ${HOME}/sandboxes), configure dbdeployer to use the
non-root sandbox directory (or pass explicit --sandbox-dir/target to dbdeployer
and adjust dbdeployer downloads/get-unpack to install under
/home/dbd/opt/mysql), ensure ENV PATH still includes the new
${HOME}/opt/mysql/9.5.0/bin, and verify file ownership/permissions for /home/dbd
so the dbd user can run entrypoint.sh and run dbdeployer without root.
- Around line 18-20: The Dockerfile currently pipes the remote dbdeployer
tarball straight into tar (the RUN that downloads dbdeployer using
DBDEPLOYER_VERSION), which skips integrity checks; change this to download the
artifact to a temporary file (e.g., /tmp/dbdeployer.tar.gz), verify its SHA256
(or GPG/gh release signature) before extraction, and only after successful
verification extract to /usr/local/bin and chmod +x the dbdeployer binary; if an
official checksum/signature isn't available, instead pin to a reproducible
commit/tag or require a hardcoded SHA256 provided via a build ARG/secure channel
(or use the gh CLI verification) so the build fails when verification cannot be
performed.
---
Duplicate comments:
In `@test/infra/infra-dbdeployer-mysql90-gr/docker/Dockerfile`:
- Around line 18-20: The Dockerfile currently streams the dbdeployer tarball
into tar without integrity checks; update the Dockerfile to fetch and verify the
release checksum/signature for the artifact identified by DBDEPLOYER_VERSION and
only extract to /usr/local/bin/dbdeployer after successful verification (e.g.,
download accompanying .sha256 or .asc from the release, verify with sha256sum or
gpg, then tar -xz and chmod), referencing DBDEPLOYER_VERSION and
/usr/local/bin/dbdeployer to locate the steps; if no checksum/signature is
available for that release, add an explicit comment in the Dockerfile
documenting that TLS-only trust for the GitHub release artifact is an
acknowledged CI risk.
In `@test/infra/infra-dbdeployer-mysql93-gr/docker/Dockerfile`:
- Around line 18-20: The Dockerfile currently streams the remote dbdeployer
tarball directly into tar (the RUN command using DBDEPLOYER_VERSION), so add
checksum verification: download the tarball and its accompanying checksum (e.g.,
.sha256 or .sha256sum for the same DBDEPLOYER_VERSION) into a temporary
location, verify the archive with sha256sum (or openssl dgst) and only if
verification succeeds, extract to /usr/local/bin/ and chmod +x
/usr/local/bin/dbdeployer; reference DBDEPLOYER_VERSION and the
/usr/local/bin/dbdeployer target when implementing the download, verification,
extraction and cleanup steps.
In `@test/infra/infra-dbdeployer-mysql93/docker/Dockerfile`:
- Around line 18-20: The Dockerfile currently pipes the remote dbdeployer
tarball directly into tar (using DBDEPLOYER_VERSION) which skips integrity
checks; change the steps to first download the tarball and its checksum (for the
matching v${DBDEPLOYER_VERSION} release) to temporary files, verify the checksum
(e.g., with sha256sum -c or sha256sum --check) and abort on mismatch, and only
after successful verification extract to /usr/local/bin/ (instead of piping into
tar -xz -C) and set chmod +x on /usr/local/bin/dbdeployer; ensure the commands
reference DBDEPLOYER_VERSION and fail the build if verification fails.
---
Nitpick comments:
In `@test/infra/infra-dbdeployer-mysql90-gr/docker/Dockerfile`:
- Around line 1-38: The Dockerfile and entrypoint.sh hardcode root-only paths
(/root/opt/mysql, /root/sandboxes) and run as root with no USER directive;
either document this root-only requirement in the Dockerfile comments and
README, or refactor to support non-root execution by introducing a configurable
base directory environment variable (e.g., BASE_DIR with default /root), update
references in the Dockerfile (ENV PATH to use ${BASE_DIR}/opt/mysql) and
entrypoint.sh to read BASE_DIR, and optionally add a USER creation/CHOWN flow or
document why USER cannot be changed; look for symbols and files named
Dockerfile, entrypoint.sh, PATH/ENV lines, dbdeployer download/install steps,
and reserved-ports update to ensure all /root occurrences are replaced or
parameterized.
In `@test/infra/infra-dbdeployer-mysql93-gr/docker/Dockerfile`:
- Line 3: The Dockerfile currently hardcodes MySQL version "9.3.0" in multiple
places; introduce a single ARG (e.g., MYSQL_VERSION or DBDEPLOYER_MYSQL_VERSION)
at the top (like the existing ARG DBDEPLOYER_VERSION) and replace every
hardcoded "9.3.0" occurrence with that ARG reference so both the base image and
any other instructions use the same centralized version variable (update
occurrences near where the Dockerfile uses the MySQL base image and any
package/version installs).
In `@test/infra/infra-dbdeployer-mysql93/docker/Dockerfile`:
- Line 3: The Dockerfile currently hardcodes the MySQL client/server/version
string (e.g., "9.3.0") in multiple places; introduce a single ARG like
MYSQL_VERSION and replace all literal "9.3.0" occurrences with that variable to
avoid drift. Add ARG MYSQL_VERSION=<current-version> alongside ARG
DBDEPLOYER_VERSION, then update the Dockerfile instructions that reference the
version (the commands/lines that currently include "9.3.0") to use
${MYSQL_VERSION} so all references point to the single source of truth.
In `@test/infra/infra-dbdeployer-mysql95-gr/docker/Dockerfile`:
- Around line 1-38: The Dockerfile currently hard-codes /root paths preventing
safe USER switching; change installation and runtime paths to a non-root
location and make them configurable: introduce an ENV like
DBDEPLOYER_HOME=/opt/dbdeployer (or /opt/mysql), update the dbdeployer
download/unpack target and the mkdir target from /root/opt/mysql and
/root/sandboxes to use ${DBDEPLOYER_HOME} and a sandboxes subdir, update ENV
PATH to include ${DBDEPLOYER_HOME}/9.5.0/bin, and refactor entrypoint.sh and
docker-mysql-post.bash to read DBDEPLOYER_HOME (or derive from $DBDEPLOYER_HOME)
instead of /root paths so you can safely add a USER instruction and run as
non-root.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 7c2b9970-fd74-4bc2-a90e-8bee41070cef
📒 Files selected for processing (7)
test/infra/infra-dbdeployer-mysql90-gr/docker/Dockerfiletest/infra/infra-dbdeployer-mysql90/docker/Dockerfiletest/infra/infra-dbdeployer-mysql93-gr/docker/Dockerfiletest/infra/infra-dbdeployer-mysql93/docker/Dockerfiletest/infra/infra-dbdeployer-mysql95-gr/docker/Dockerfiletest/infra/infra-dbdeployer-mysql95/docker/Dockerfiletest/tap/groups/groups.json
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
- GitHub Check: CI-builds / builds (debian12,-dbg)
- GitHub Check: CI-builds / builds (ubuntu22,-tap)
- GitHub Check: CI-builds / builds (ubuntu24,-tap-genai-gcov)
- GitHub Check: run / trigger
- GitHub Check: claude-review
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: CR
Repo: sysown/proxysql PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-12T11:27:41.142Z
Learning: Refer to `doc/agents/project-conventions.md` for ProxySQL-specific rules on directories, build, test harness, and git workflow
Learnt from: CR
Repo: sysown/proxysql PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-12T11:27:41.142Z
Learning: Applies to **/*.{cpp,h,hpp} : Feature tiers controlled by flags: `PROXYSQL31=1` for v3.1.x (FFTO, TSDB), `PROXYSQLGENAI=1` for v4.0.x (GenAI, MCP, Anomaly Detection). `PROXYSQLGENAI=1` implies `PROXYSQL31=1` which implies `PROXYSQLFFTO=1` and `PROXYSQLTSDB=1`
📚 Learning: 2026-04-12T11:27:41.142Z
Learnt from: CR
Repo: sysown/proxysql PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-12T11:27:41.142Z
Learning: Refer to `doc/agents/project-conventions.md` for ProxySQL-specific rules on directories, build, test harness, and git workflow
Applied to files:
test/infra/infra-dbdeployer-mysql93/docker/Dockerfile
🪛 Trivy (0.69.3)
test/infra/infra-dbdeployer-mysql90-gr/docker/Dockerfile
[error] 1-1: Image user should not be 'root'
Specify at least 1 USER command in Dockerfile with non-root user as argument
Rule: DS-0002
(IaC/Dockerfile)
test/infra/infra-dbdeployer-mysql90/docker/Dockerfile
[error] 1-1: Image user should not be 'root'
Specify at least 1 USER command in Dockerfile with non-root user as argument
Rule: DS-0002
(IaC/Dockerfile)
test/infra/infra-dbdeployer-mysql93-gr/docker/Dockerfile
[error] 1-1: Image user should not be 'root'
Specify at least 1 USER command in Dockerfile with non-root user as argument
Rule: DS-0002
(IaC/Dockerfile)
test/infra/infra-dbdeployer-mysql93/docker/Dockerfile
[error] 1-1: Image user should not be 'root'
Specify at least 1 USER command in Dockerfile with non-root user as argument
Rule: DS-0002
(IaC/Dockerfile)
test/infra/infra-dbdeployer-mysql95-gr/docker/Dockerfile
[error] 1-1: Image user should not be 'root'
Specify at least 1 USER command in Dockerfile with non-root user as argument
Rule: DS-0002
(IaC/Dockerfile)
test/infra/infra-dbdeployer-mysql95/docker/Dockerfile
[error] 1-1: Image user should not be 'root'
Specify at least 1 USER command in Dockerfile with non-root user as argument
Rule: DS-0002
(IaC/Dockerfile)
🔇 Additional comments (8)
test/infra/infra-dbdeployer-mysql93/docker/Dockerfile (1)
8-15: Dependency bootstrap block looks good.
apt-getusage is clean (--no-install-recommends+ apt lists cleanup), which keeps the image lean and deterministic enough for CI infra.test/infra/infra-dbdeployer-mysql93-gr/docker/Dockerfile (1)
8-15: Dependency bootstrap block is solid.Good use of
--no-install-recommendsand apt cache cleanup for CI image hygiene.test/infra/infra-dbdeployer-mysql90/docker/Dockerfile (5)
1-15: LGTM: Base image and dependencies are appropriate.The Ubuntu 22.04 base with MySQL-required system libraries (libaio1, libnuma1, libncurses5) and proper apt cache cleanup follows container best practices.
17-20: dbdeployer v2.2.1 exists and is downloadable. The specified version is available in the ProxySQL/dbdeployer repository, and the download URL is valid. No action needed.
33-38: Add a USER directive to run the container as a non-root user.The container currently runs as root (flagged by static analysis DS-0002). However, dbdeployer supports and is designed for non-root operation—it runs as the current user and manages sandboxes in
$HOME/sandboxesby default. Adding aUSERdirective with a non-root user after the initial setup would improve security hardening even for test infrastructure.
22-24: The tarball name is correct. ProxySQL's v2 dbdeployer (which supports MySQL 9.0+) either includesmysql-9.0.1-linux-glibc2.17-x86_64.tar.xzpre-cached or fetches it dynamically from dev.mysql.com. The naming format matches other MySQL 9.x versions in the repo (9.3.0, 9.5.0) and the PR's smoke test confirms the command works.
26-31: The reserved-ports configuration and MySQL path are consistent with the established pattern across all similar Dockerfiles in the repository (MySQL 5.7, 8.4, 9.0, 9.3, 9.5, and MariaDB). The syntaxreserved-ports '0'and the path structureENV PATH="/root/opt/mysql/<VERSION>/bin:${PATH}"match the tarball version in the get-unpack command and are used identically in all infra-dbdeployer Dockerfiles, indicating this is the standard approach for this project.test/infra/infra-dbdeployer-mysql95-gr/docker/Dockerfile (1)
18-20: Already reported: add checksum verification fordbdeployerdownload.Same supply-chain issue remains at Line 18-Line 20 (
curl | tarwithout integrity check), and it matches the existing review thread.
| FROM ubuntu:22.04 | ||
|
|
||
| ARG DBDEPLOYER_VERSION=2.2.1 | ||
|
|
||
| ENV DEBIAN_FRONTEND=noninteractive | ||
|
|
||
| # System dependencies required by MySQL 9.5 | ||
| RUN apt-get update && apt-get install -y --no-install-recommends \ | ||
| libaio1 \ | ||
| libnuma1 \ | ||
| libncurses5 \ | ||
| perl \ | ||
| curl \ | ||
| ca-certificates \ | ||
| && rm -rf /var/lib/apt/lists/* | ||
|
|
||
| # Install dbdeployer | ||
| RUN curl -fsSL "https://github.com/ProxySQL/dbdeployer/releases/download/v${DBDEPLOYER_VERSION}/dbdeployer-${DBDEPLOYER_VERSION}.linux_amd64.tar.gz" \ | ||
| | tar -xz -C /usr/local/bin/ \ | ||
| && chmod +x /usr/local/bin/dbdeployer | ||
|
|
||
| # Download and unpack MySQL 9.5 tarball using dbdeployer (pre-baked so no download at runtime) | ||
| RUN mkdir -p /root/opt/mysql \ | ||
| && dbdeployer downloads get-unpack mysql-9.5.0-linux-glibc2.17-x86_64.tar.xz | ||
|
|
||
| # Clear reserved ports so dbdeployer allows base-port 3305 (nodes get 3306,3307,3308) | ||
| # dbdeployer reserves 1186,3306,5432,33060,33062 by default; replace with harmless value | ||
| RUN dbdeployer defaults update reserved-ports '0' | ||
|
|
||
| # Make MySQL client available in PATH for docker exec health checks | ||
| ENV PATH="/root/opt/mysql/9.5.0/bin:${PATH}" | ||
|
|
||
| COPY entrypoint.sh /entrypoint.sh | ||
| RUN chmod +x /entrypoint.sh | ||
|
|
||
| EXPOSE 3306 3307 3308 | ||
|
|
||
| ENTRYPOINT ["/entrypoint.sh"] |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Verify whether this infra's scripts are coupled to /root paths before switching USER.
rg -n -C2 '/root/opt/mysql|/root/' test/infra/infra-dbdeployer-mysql95Repository: sysown/proxysql
Length of output: 2749
🏁 Script executed:
cat -n test/infra/infra-dbdeployer-mysql95/docker/entrypoint.shRepository: sysown/proxysql
Length of output: 6047
🏁 Script executed:
cat -n test/infra/infra-dbdeployer-mysql95/bin/docker-mysql-post.bashRepository: sysown/proxysql
Length of output: 2857
The suggested refactoring pattern is incomplete and would break the entrypoint script.
While dropping root is a valid security improvement (DS-0002), the provided minimal pattern ignores that entrypoint.sh (lines 10, 40) and docker-mysql-post.bash (line 50) hardcode /root paths. Switching to the dbd user without updating these scripts will cause the container to fail at runtime when entrypoint.sh attempts to access /root/opt/mysql/ and /root/sandboxes/.
A complete refactoring must also:
- Update
entrypoint.shto use/home/dbd/opt/mysqland/home/dbd/sandboxes(or reference${HOME}) - Ensure
dbdeployeris configured to deploy to the non-root location, or adjust the deploy commands to redirect output - Update
docker-mysql-post.bashline 50 to query/home/dbd/sandboxes/instead of/root/sandboxes/
🧰 Tools
🪛 Trivy (0.69.3)
[error] 1-1: Image user should not be 'root'
Specify at least 1 USER command in Dockerfile with non-root user as argument
Rule: DS-0002
(IaC/Dockerfile)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/infra/infra-dbdeployer-mysql95/docker/Dockerfile` around lines 1 - 38,
The proposed switch-to-nonroot change breaks hardcoded /root paths used by
entrypoint.sh and docker-mysql-post.bash and dbdeployer’s download location;
update entrypoint.sh and docker-mysql-post.bash to reference ${HOME} or
/home/dbd (e.g., replace /root/opt/mysql and /root/sandboxes with
${HOME}/opt/mysql and ${HOME}/sandboxes), configure dbdeployer to use the
non-root sandbox directory (or pass explicit --sandbox-dir/target to dbdeployer
and adjust dbdeployer downloads/get-unpack to install under
/home/dbd/opt/mysql), ensure ENV PATH still includes the new
${HOME}/opt/mysql/9.5.0/bin, and verify file ownership/permissions for /home/dbd
so the dbd user can run entrypoint.sh and run dbdeployer without root.
| RUN curl -fsSL "https://github.com/ProxySQL/dbdeployer/releases/download/v${DBDEPLOYER_VERSION}/dbdeployer-${DBDEPLOYER_VERSION}.linux_amd64.tar.gz" \ | ||
| | tar -xz -C /usr/local/bin/ \ | ||
| && chmod +x /usr/local/bin/dbdeployer |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
VER="2.2.1"
BASE="https://github.com/ProxySQL/dbdeployer/releases/download/v${VER}"
FILE="dbdeployer-${VER}.linux_amd64.tar.gz"
curl -fsSL -o /tmp/${FILE} "${BASE}/${FILE}"
curl -fsSL "${BASE}/checksums.txt" | rg "${FILE}" > /tmp/dbdeployer.check
sha256sum -c /tmp/dbdeployer.checkRepository: sysown/proxysql
Length of output: 108
🌐 Web query:
dbdeployer GitHub releases checksums verification 2.2.1
💡 Result:
No dbdeployer version 2.2.1 release exists on GitHub. The primary dbdeployer repository (datacharmer/dbdeployer) is archived since Oct 2023, with latest release v1.73.0 (Jul 2023). It added SHA256 checksum files starting v1.50.0 (May 2020) for verification during updates: "Add checksum files (SHA256) to release * Add signature check during dbdeployer update". The alternative covermymeds/dbdeployer (database deployment tool, latest v1.5.10, 2021) has no 2.2.1. GitHub releases typically lack separate checksum files; verification uses tools like GitHub CLI 'gh release download --verify'. No evidence found for 2.2.1 checksums as no such release exists.
Citations:
- 1: https://github.com/datacharmer/dbdeployer/releases
- 2: https://github.com/datacharmer/dbdeployer
- 3: https://github.com/covermymeds/dbdeployer
- 4: https://github.com/datacharmer/dbdeployer/blob/master/CHANGELOG.md
- 5: https://linkedin.com/in/cj-estel-21383614
🌐 Web query:
ProxySQL dbdeployer version 2.2.1 GitHub repository
💡 Result:
The GitHub repository for ProxySQL's dbdeployer (version 2.2.1) is https://github.com/ProxySQL/dbdeployer. The original datacharmer/dbdeployer repository is archived and redirects development to ProxySQL's fork, where v2.x development continues, including v2.1.1 and likely 2.2.1 as mentioned in the query. Install script: curl -s https://raw.githubusercontent.com/ProxySQL/dbdeployer/master/scripts/dbdeployer-install.sh | bash. Blog confirms ProxySQL took over dbdeployer, with v2.1.1 released featuring MySQL/PostgreSQL support, replication topologies, and ProxySQL integration.
Citations:
- 1: https://github.com/datacharmer/dbdeployer
- 2: https://proxysql.com/blog/proxysql-dbdeployer-whats-coming/
- 3: https://proxysql.com/blog/proxysql-dbdeployer-whats-coming
🌐 Web query:
ProxySQL dbdeployer releases checksums SHA256 verification
💡 Result:
ProxySQL provides SHA256 checksums for its official releases on GitHub (https://github.com/sysown/proxysql/releases), listed in each release's "Hashes" section. For example, ProxySQL 4.0.7 includes checksums like "4264b5337e8458e515e07449311264b8fa882fca7bb1c1aadcb581b9efdc6da7 proxysql-4.0.7-1-almalinux10-clang.x86_64.rpm". Download the assets and verify using sha256sum -c or equivalent. dbdeployer, now maintained by ProxySQL at https://github.com/ProxySQL/dbdeployer (mentioned in ProxySQL blog posts from 2026), follows similar GitHub release practices. Original dbdeployer releases at https://github.com/datacharmer/dbdeployer/releases/tag/v1.73.0 provide separate .sha256 files alongside binaries (e.g., dbdeployer-1.73.0.linux.tar.gz.sha256). Verify by downloading both the archive and its .sha256 file, then sha256sum -c *.sha256. dbdeployer itself supports SHA256 verification for MySQL tarballs it downloads (prefixed format like "SHA256:hash"), as documented in its README template and CHANGELOG (added in v1.50.0). Use dbdeployer downloads commands with checksums for safe MySQL binary fetching before sandbox deployment. No centralized ProxySQL/dbdeployer-specific checksum page found; use per-release GitHub assets. For installation scripts like dbdeployer-install.sh, verify the script source via GitHub commit hash before piping to bash.
Citations:
- 1: https://github.com/sysown/proxysql/releases
- 2: https://github.com/datacharmer/dbdeployer
- 3: https://proxysql.com/blog/proxysql-dbdeployer-whats-coming/
- 4: https://github.com/datacharmer/dbdeployer/releases/tag/v1.73.0
- 5: https://github.com/datacharmer/dbdeployer/blob/master/CHANGELOG.md
- 6: https://www.proxysql.com
- 7: https://www.andus.co.jp
- 8: https://github.com/datacharmer/dbdeployer/releases/tag/v1.19.0
🌐 Web query:
site:github.com/ProxySQL/dbdeployer/releases dbdeployer-2.2.1 sha256 checksum
💡 Result:
I couldn’t find any published SHA256 checksum for dbdeployer-2.2.1 under ProxySQL/dbdeployer (no checksums.txt, .sha256, or checksum lines appear on the v2.2.1 release page HTML; the “Assets” section doesn’t expose checksums in the fetched content). The release page only shows the direct download URLs for the binaries (e.g., dbdeployer-2.2.1-linux-amd64 and dbdeployer-2.2.1-darwin-arm64). [1]
If you just need the SHA256, you’ll have to compute it locally after downloading, e.g.:
curl -L -O https://github.com/ProxySQL/dbdeployer/releases/download/v2.2.1/dbdeployer-2.2.1-linux-amd64
sha256sum dbdeployer-2.2.1-linux-amd64Sources:
[1] ProxySQL/dbdeployer v2.2.1 release page (download URLs shown, no checksum listed) (github.com)
Citations:
Verify dbdeployer artifact integrity before extraction.
At lines 18–20, piping a remote tarball directly into tar skips integrity verification, weakening CI supply-chain safety. However, ProxySQL/dbdeployer v2.2.1 does not publish SHA256 checksums on its GitHub release page, so the suggested hardening approach using checksums.txt is not feasible.
Consider alternative approaches:
- Request ProxySQL/dbdeployer maintainers publish checksums or signed releases
- Pin to a commit hash instead of release tag for binary reproducibility
- Download and verify against a hardcoded SHA256 hash obtained from a secure out-of-band channel
- Use GitHub's official release verification tool (requires
ghCLI)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/infra/infra-dbdeployer-mysql95/docker/Dockerfile` around lines 18 - 20,
The Dockerfile currently pipes the remote dbdeployer tarball straight into tar
(the RUN that downloads dbdeployer using DBDEPLOYER_VERSION), which skips
integrity checks; change this to download the artifact to a temporary file
(e.g., /tmp/dbdeployer.tar.gz), verify its SHA256 (or GPG/gh release signature)
before extraction, and only after successful verification extract to
/usr/local/bin and chmod +x the dbdeployer binary; if an official
checksum/signature isn't available, instead pin to a reproducible commit/tag or
require a hardcoded SHA256 provided via a build ARG/secure channel (or use the
gh CLI verification) so the build fails when verification cannot be performed.
Mirrors the existing infra-dbdeployer-mysql84-binlog layout (3-node
replication + proxysql_binlog_reader on GTID ports 6020/6021/6022) for
MySQL 9.0 and 9.5. Group replication binlog variant not requested; skipped.
New infrastructures:
test/infra/infra-dbdeployer-mysql{90,95}-binlog/
Hostgroup PREFIX assignment:
mysql90-binlog PREFIX=37 (WHG/RHG/BHG/OHG = 3700/3701/3702/3703)
mysql95-binlog PREFIX=38 (3800/3801/3802/3803)
MySQL tarballs (x86_64 glibc2.17 variants, same as the standalone 9.x infras):
mysql-9.0.1-linux-glibc2.17-x86_64.tar.xz
mysql-9.5.0-linux-glibc2.17-x86_64.tar.xz
Dropped the `-c mysql_native_password=ON` dbdeployer flag and the
`IDENTIFIED WITH 'mysql_native_password'` clause, same as the other 9.x
infras, since the plugin isn't usable on MySQL 9.x servers.
Group wiring (test/tap/groups/):
mysql{90,95}-binlog/ — env.sh + infras.lst, mirroring mysql84-binlog/
groups.json: registered mysql90-binlog-g[12] and mysql95-binlog-g[12]
mirroring mysql84-binlog-g[12] exactly (g1=3 tests, g2=1 test).
check_groups.py reports 385/385 registered.
KNOWN LIMITATION — proxysql_binlog_reader v2.3 cannot authenticate:
Smoke test of mysql90-binlog confirmed 3-node replication deploys
cleanly and users replicate, but the binlog reader processes fail
to start with:
Could not mysql_real_connect():
Authentication plugin 'caching_sha2_password' reported error:
Authentication requires secure connection. : 2061
Root cause: the bundled proxysql_binlog_reader v2.3 supports only
-h/-u/-p/-P/-l/-L options — no SSL, no --get-server-public-key.
MySQL 9.x's default caching_sha2_password requires either SSL or a
preconfigured RSA public key, neither of which the reader can provide.
mysql_native_password isn't a workable escape hatch on 9.x either:
the .so still ships in the tarball but `INSTALL PLUGIN` fails with
"Can't find symbol '_mysql_plugin_interface_version_'" — it's kept
as a client library stub only.
Resolution requires either (a) a newer proxysql_binlog_reader that
speaks caching_sha2_password or supports SSL, or (b) SSL wrapping
at the container level. Neither change is part of this commit;
flagging here so the limitation is visible when the tests start
failing under mysql{90,95}-binlog-g[12].
MySQL 8.4 binlog flow is unaffected.
There was a problem hiding this comment.
Actionable comments posted: 9
🧹 Nitpick comments (7)
test/infra/infra-dbdeployer-mysql95-binlog/docker/entrypoint.sh (1)
36-36: Deprecated option name:slave_net_timeout.MySQL 8.0.26+ renamed
slave_net_timeouttoreplica_net_timeout. While the old name may still work as an alias, using the new name improves clarity and future compatibility.🔧 Suggested fix
- -c slave_net_timeout=4 \ + -c replica_net_timeout=4 \🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql95-binlog/docker/entrypoint.sh` at line 36, The startup option uses the deprecated MySQL variable name slave_net_timeout in the docker entrypoint script; update that option to the newer name replica_net_timeout (replace slave_net_timeout=4 with replica_net_timeout=4 in the entrypoint.sh invocation) so the server uses the supported variable name and avoids deprecation/compatibility issues.test/infra/infra-dbdeployer-mysql95-binlog/docker-compose-init.bash (3)
46-51: Consider separating declaration and assignment for ROOT_PASSWORD.While functional, separating declaration and assignment prevents masking the
sha256sumexit code.🔧 Suggested fix
if [ -z "${INFRA_ID}" ]; then echo "Error: INFRA_ID must be set"; exit 1; fi -export ROOT_PASSWORD=$(echo -n "${INFRA_ID}" | sha256sum | head -c 10) +ROOT_PASSWORD=$(echo -n "${INFRA_ID}" | sha256sum | head -c 10) +export ROOT_PASSWORD export INFRA=${PWD##*/}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql95-binlog/docker-compose-init.bash` around lines 46 - 51, The current one-liner assigns ROOT_PASSWORD using command substitution which can mask the exit status of sha256sum; instead, declare ROOT_PASSWORD first, compute the hash into a temporary variable by running `sha256sum` (capturing its exit code), check the command succeeded, then set ROOT_PASSWORD=$(echo -n "$temp" | head -c 10) (references: ROOT_PASSWORD and sha256sum) so failures are detected and handled before assignment.
27-27: Quote command substitution.Same issue as in destroy script—unquoted
$(dirname $0)can break with paths containing spaces.🔧 Suggested fix
-pushd $(dirname $0) &>/dev/null +pushd "$(dirname "$0")" &>/dev/null🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql95-binlog/docker-compose-init.bash` at line 27, The pushd invocation uses unquoted command substitution which breaks on paths with spaces; update the invocation to quote the dirname expansion so pushd "$(dirname "$0")" is used instead of pushd $(dirname $0), and apply the same quoting pattern used in the destroy script; modify the pushd call in docker-compose-init.bash (the pushd + dirname "$0" expression) to wrap both the substitution and $0 in quotes to ensure path safety.
3-9: Quote command substitutions to improve robustness.The INFRA_ID derivation uses nested command substitutions that could break with paths containing spaces.
🔧 Suggested fix
if [ -z "${INFRA_ID}" ]; then - export INFRA_ID=$(basename $(dirname $(pwd)) | sed 's/infra-//; s/docker-//') + INFRA_ID=$(basename "$(dirname "$(pwd)")" | sed 's/infra-//; s/docker-//') + export INFRA_ID fi🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql95-binlog/docker-compose-init.bash` around lines 3 - 9, The INFRA_ID derivation uses unquoted command substitutions and variable expansions which break on paths with spaces; update the logic that sets INFRA_ID to quote all command substitutions and intermediate variables (e.g., use dirname, basename and the output of pwd wrapped in quotes) and/or assign intermediate results to quoted variables before piping into sed so that basename, dirname, pwd and sed operate on quoted inputs; ensure the final export uses a quoted expansion like export INFRA_ID="$INFRA_ID" and keep the same fallback check for empty or ".".test/infra/infra-dbdeployer-mysql95-binlog/bin/docker-proxy-post.bash (1)
11-23: Consider checking docker exec exit code directly.The
if [ $? -eq 0 ]pattern after the heredoc works but is less idiomatic than checking the command directly.🔧 Suggested improvement
-docker exec -i "${PROXY_CONTAINER}" mysql -uradmin -pradmin -h127.0.0.1 -P6032 <<SQL +if docker exec -i "${PROXY_CONTAINER}" mysql -uradmin -pradmin -h127.0.0.1 -P6032 <<SQL $(eval "echo \"$(cat ./conf/proxysql/infra-config.sql)\"") -- Additional configuration for binlog tests -- Ensure monitor credentials are synchronized UPDATE global_variables SET variable_value='monitor' WHERE variable_name='mysql-monitor_username'; UPDATE global_variables SET variable_value='monitor' WHERE variable_name='mysql-monitor_password'; LOAD MYSQL VARIABLES TO RUNTIME; SAVE MYSQL VARIABLES TO DISK; SQL - -if [ $? -eq 0 ]; then echo "Cluster ${INFRA} registered in ProxySQL."; else echo "ERROR: ProxySQL configuration FAILED for ${INFRA}"; exit 1; fi +then + echo "Cluster ${INFRA} registered in ProxySQL." +else + echo "ERROR: ProxySQL configuration FAILED for ${INFRA}" + exit 1 +fi🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql95-binlog/bin/docker-proxy-post.bash` around lines 11 - 23, The current script relies on testing $? after the heredoc which is less idiomatic; instead run the docker exec call (the mysql invocation using PROXY_CONTAINER and the heredoc of ./conf/proxysql/infra-config.sql) directly in an if conditional and branch on its exit status, so replace the separate heredoc + `if [ $? -eq 0 ]` check with an `if docker exec -i "${PROXY_CONTAINER}" mysql -uradmin -pradmin -h127.0.0.1 -P6032 <<SQL ... SQL; then echo "Cluster ${INFRA} registered in ProxySQL."; else echo "ERROR: ProxySQL configuration FAILED for ${INFRA}"; exit 1; fi` pattern to directly test the command result.test/infra/infra-dbdeployer-mysql95-binlog/docker-compose-destroy.bash (1)
4-4: Quote command substitution to handle paths with spaces.The unquoted
$(dirname $0)can cause issues if the script path contains whitespace.🔧 Suggested fix
-pushd $(dirname $0) &>/dev/null +pushd "$(dirname "$0")" &>/dev/null🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql95-binlog/docker-compose-destroy.bash` at line 4, The pushd call uses unquoted command substitution pushd $(dirname $0) which breaks on paths with spaces; update the pushd invocation so the dirname command substitution and the $0 variable are wrapped in double quotes (i.e., quote both the command substitution and the $0) so pushd receives a single correctly quoted path, referencing the pushd and dirname/$0 usage in the script.test/infra/infra-dbdeployer-mysql90-binlog/docker/entrypoint.sh (1)
36-36: Replace deprecatedslave_net_timeoutwithreplica_net_timeoutfor MySQL 9.0 forward compatibility.The
slave_net_timeoutparameter is deprecated in MySQL 9.0 in favor ofreplica_net_timeout. Using the deprecated alias triggers warnings and will be removed in a future MySQL release.Proposed fix
- -c slave_net_timeout=4 \ + -c replica_net_timeout=4 \🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/infra/infra-dbdeployer-mysql90-binlog/docker/entrypoint.sh` at line 36, Replace the deprecated MySQL option by updating the startup argument in entrypoint.sh: change any occurrence of the config flag "slave_net_timeout" (e.g., the "-c slave_net_timeout=4" argument) to the supported "replica_net_timeout" so the container uses replica_net_timeout=4 instead; update the same symbol wherever else in entrypoint.sh or related startup args to ensure forward compatibility with MySQL 9.0.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@test/infra/infra-dbdeployer-mysql90-binlog/bin/docker-mysql-post.bash`:
- Around line 40-44: The replication readiness check currently only logs a
warning when IO_RUNNING or SQL_RUNNING are not "Yes" (variables IO_RUNNING and
SQL_RUNNING) so the suite continues; change the else branch in that conditional
(the block that echoes " WARNING (IO: ${IO_RUNNING}, SQL: ${SQL_RUNNING})") to
print a clear error message and exit with a non‑zero status (e.g., exit 1) to
fail fast when replication threads are not running.
In `@test/infra/infra-dbdeployer-mysql90-binlog/bin/docker-proxy-post.bash`:
- Around line 11-13: Replace the unsafe eval-based SQL templating in the docker
exec invocation by using envsubst and a script-relative path: avoid using eval
on "$(cat ./conf/proxysql/infra-config.sql)" and instead read the template from
SCRIPT_DIR/conf/proxysql/infra-config.sql, pipe it through envsubst (exporting
variables such as ROOT_PASSWORD and INFRA) and feed the result into the same
docker exec mysql command that uses PROXY_CONTAINER; ensure SCRIPT_DIR is
computed (e.g., from ${BASH_SOURCE[0]}) and required env vars are exported
before calling envsubst so no shell evaluation of template content occurs.
In `@test/infra/infra-dbdeployer-mysql90-binlog/conf/proxysql/infra-config.sql`:
- Line 14: The DELETE in mysql_replication_hostgroups is unscoped and removes
rows across the whole cluster (it targets comment='.' OR comment='' OR comment
IS NULL); change it to only remove rows owned by this infra by adding a
restrictive WHERE clause that targets your infra's identifier (for example WHERE
comment LIKE 'infra:%' or WHERE comment = '<your_infra_id>') or by restricting
to specific hostgroup IDs/cluster identifiers used by this deployment; update
the statement operating on mysql_replication_hostgroups and the comment column
so it only affects rows belonging to this infra.
In `@test/infra/infra-dbdeployer-mysql90-binlog/docker-compose-destroy.bash`:
- Around line 7-11: Validate INFRA_ID before constructing COMPOSE_PROJECT and
add a docker CLI fallback: check that INFRA_ID is non-empty and exit with a
clear error if it is unset (so COMPOSE_PROJECT="${INFRA}-${INFRA_ID}" is never
constructed from an empty INFRA_ID), and replace the hardcoded "docker compose
-p \"${COMPOSE_PROJECT}\" down -v" call with logic that detects whether the
system provides the `docker compose` subcommand or only the legacy
`docker-compose` binary and invokes the available one accordingly; update the
symbols INFRA_ID, COMPOSE_PROJECT and the down invocation to use the chosen CLI.
In `@test/infra/infra-dbdeployer-mysql90-binlog/docker-compose-init.bash`:
- Around line 3-5: The INFRA_ID derivation uses $(pwd) which is caller-CWD
dependent; change it to compute the project directory from the script's own
location instead (use the script directory via dirname "$0" or BASH_SOURCE and
cd there before deriving the basename), then apply the same sed transformations;
update the export INFRA_ID assignment (the symbol INFRA_ID) so it uses the
script-resolved path rather than $(pwd) to ensure a consistent network identity
regardless of where the script is invoked.
- Line 106: The current invocation using COMPOSE_CMD with two --env-file args
can break when COMPOSE_CMD is the legacy docker-compose; detect whether
COMPOSE_CMD is legacy (e.g., check if "$COMPOSE_CMD" name equals
"docker-compose" or parse "$COMPOSE_CMD version" output) and if so merge .env
and "${ENV_FILE}" into a temporary combined env file (ensure proper key
precedence and cleanup) and call $COMPOSE_CMD with a single --env-file pointing
to that temp file; otherwise (modern docker compose) keep the two --env-file
arguments as-is. Reference: COMPOSE_CMD, ENV_FILE, .env, COMPOSE_PROJECT and the
existing up -d invocation.
In `@test/infra/infra-dbdeployer-mysql90-binlog/docker/Dockerfile`:
- Around line 24-27: The Dockerfile currently downloads and extracts dbdeployer
in the RUN step using DBDEPLOYER_VERSION without verifying integrity; update the
RUN sequence that references DBDEPLOYER_VERSION and /usr/local/bin/dbdeployer to
first fetch the published checksum (or signature) from the ProxySQL/dbdeployer
release assets (e.g., .sha256 or .asc), verify the downloaded tarball against
that checksum (using sha256sum -c or gpg --verify) and only extract on success,
and if no checksum/signature is published add a clear comment documenting the
pinned DBDEPLOYER_VERSION and the lack of published checksums and/or consider
switching to a verified upstream or embedding a known-good checksum variable for
reproducible builds.
In `@test/infra/infra-dbdeployer-mysql90-binlog/docker/entrypoint.sh`:
- Around line 162-176: The loop that checks reader ports prints " OK"
unconditionally even after a timeout; update the loop around
READER_PORT/READER_PORTS so that success is detected and " OK" is printed only
when the TCP connection succeeds: introduce a success flag (e.g., SUCCESS=0
before the while), set SUCCESS=1 if the bash -c connection succeeds (or set
after the while only if COUNT < MAX_WAIT), and after the loop echo " OK" only
when SUCCESS is true; otherwise leave the warning as-is (do not print " OK"
after the timeout).
In `@test/infra/infra-dbdeployer-mysql95-binlog/bin/docker-mysql-post.bash`:
- Line 60: The chmod invocation assumes both DB_BUNDLE and CA_BUNDLE exist;
update the script around the line with [ -f "${DB_BUNDLE}" ] && sudo chmod 666
"${DB_BUNDLE}" "${CA_BUNDLE}" || true to guard each file individually or check
both exist first: ensure you test -f for "${DB_BUNDLE}" and -f for
"${CA_BUNDLE}" (or run separate guarded chmods) so chmod is only called on files
that actually exist; reference DB_BUNDLE and CA_BUNDLE and modify the
conditional logic accordingly.
---
Nitpick comments:
In `@test/infra/infra-dbdeployer-mysql90-binlog/docker/entrypoint.sh`:
- Line 36: Replace the deprecated MySQL option by updating the startup argument
in entrypoint.sh: change any occurrence of the config flag "slave_net_timeout"
(e.g., the "-c slave_net_timeout=4" argument) to the supported
"replica_net_timeout" so the container uses replica_net_timeout=4 instead;
update the same symbol wherever else in entrypoint.sh or related startup args to
ensure forward compatibility with MySQL 9.0.
In `@test/infra/infra-dbdeployer-mysql95-binlog/bin/docker-proxy-post.bash`:
- Around line 11-23: The current script relies on testing $? after the heredoc
which is less idiomatic; instead run the docker exec call (the mysql invocation
using PROXY_CONTAINER and the heredoc of ./conf/proxysql/infra-config.sql)
directly in an if conditional and branch on its exit status, so replace the
separate heredoc + `if [ $? -eq 0 ]` check with an `if docker exec -i
"${PROXY_CONTAINER}" mysql -uradmin -pradmin -h127.0.0.1 -P6032 <<SQL ... SQL;
then echo "Cluster ${INFRA} registered in ProxySQL."; else echo "ERROR: ProxySQL
configuration FAILED for ${INFRA}"; exit 1; fi` pattern to directly test the
command result.
In `@test/infra/infra-dbdeployer-mysql95-binlog/docker-compose-destroy.bash`:
- Line 4: The pushd call uses unquoted command substitution pushd $(dirname $0)
which breaks on paths with spaces; update the pushd invocation so the dirname
command substitution and the $0 variable are wrapped in double quotes (i.e.,
quote both the command substitution and the $0) so pushd receives a single
correctly quoted path, referencing the pushd and dirname/$0 usage in the script.
In `@test/infra/infra-dbdeployer-mysql95-binlog/docker-compose-init.bash`:
- Around line 46-51: The current one-liner assigns ROOT_PASSWORD using command
substitution which can mask the exit status of sha256sum; instead, declare
ROOT_PASSWORD first, compute the hash into a temporary variable by running
`sha256sum` (capturing its exit code), check the command succeeded, then set
ROOT_PASSWORD=$(echo -n "$temp" | head -c 10) (references: ROOT_PASSWORD and
sha256sum) so failures are detected and handled before assignment.
- Line 27: The pushd invocation uses unquoted command substitution which breaks
on paths with spaces; update the invocation to quote the dirname expansion so
pushd "$(dirname "$0")" is used instead of pushd $(dirname $0), and apply the
same quoting pattern used in the destroy script; modify the pushd call in
docker-compose-init.bash (the pushd + dirname "$0" expression) to wrap both the
substitution and $0 in quotes to ensure path safety.
- Around line 3-9: The INFRA_ID derivation uses unquoted command substitutions
and variable expansions which break on paths with spaces; update the logic that
sets INFRA_ID to quote all command substitutions and intermediate variables
(e.g., use dirname, basename and the output of pwd wrapped in quotes) and/or
assign intermediate results to quoted variables before piping into sed so that
basename, dirname, pwd and sed operate on quoted inputs; ensure the final export
uses a quoted expansion like export INFRA_ID="$INFRA_ID" and keep the same
fallback check for empty or ".".
In `@test/infra/infra-dbdeployer-mysql95-binlog/docker/entrypoint.sh`:
- Line 36: The startup option uses the deprecated MySQL variable name
slave_net_timeout in the docker entrypoint script; update that option to the
newer name replica_net_timeout (replace slave_net_timeout=4 with
replica_net_timeout=4 in the entrypoint.sh invocation) so the server uses the
supported variable name and avoids deprecation/compatibility issues.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 86bdb196-cbc8-4a97-b9f1-e886f3803445
📒 Files selected for processing (25)
test/infra/infra-dbdeployer-mysql90-binlog/.envtest/infra/infra-dbdeployer-mysql90-binlog/bin/docker-mysql-post.bashtest/infra/infra-dbdeployer-mysql90-binlog/bin/docker-proxy-post.bashtest/infra/infra-dbdeployer-mysql90-binlog/conf/proxysql/infra-config.sqltest/infra/infra-dbdeployer-mysql90-binlog/docker-compose-destroy.bashtest/infra/infra-dbdeployer-mysql90-binlog/docker-compose-init.bashtest/infra/infra-dbdeployer-mysql90-binlog/docker-compose.ymltest/infra/infra-dbdeployer-mysql90-binlog/docker/Dockerfiletest/infra/infra-dbdeployer-mysql90-binlog/docker/build.shtest/infra/infra-dbdeployer-mysql90-binlog/docker/entrypoint.shtest/infra/infra-dbdeployer-mysql95-binlog/.envtest/infra/infra-dbdeployer-mysql95-binlog/bin/docker-mysql-post.bashtest/infra/infra-dbdeployer-mysql95-binlog/bin/docker-proxy-post.bashtest/infra/infra-dbdeployer-mysql95-binlog/conf/proxysql/infra-config.sqltest/infra/infra-dbdeployer-mysql95-binlog/docker-compose-destroy.bashtest/infra/infra-dbdeployer-mysql95-binlog/docker-compose-init.bashtest/infra/infra-dbdeployer-mysql95-binlog/docker-compose.ymltest/infra/infra-dbdeployer-mysql95-binlog/docker/Dockerfiletest/infra/infra-dbdeployer-mysql95-binlog/docker/build.shtest/infra/infra-dbdeployer-mysql95-binlog/docker/entrypoint.shtest/tap/groups/groups.jsontest/tap/groups/mysql90-binlog/env.shtest/tap/groups/mysql90-binlog/infras.lsttest/tap/groups/mysql95-binlog/env.shtest/tap/groups/mysql95-binlog/infras.lst
✅ Files skipped from review due to trivial changes (7)
- test/tap/groups/mysql95-binlog/infras.lst
- test/tap/groups/mysql90-binlog/infras.lst
- test/tap/groups/mysql90-binlog/env.sh
- test/infra/infra-dbdeployer-mysql90-binlog/docker/build.sh
- test/infra/infra-dbdeployer-mysql95-binlog/docker/build.sh
- test/tap/groups/mysql95-binlog/env.sh
- test/infra/infra-dbdeployer-mysql95-binlog/docker-compose.yml
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
- GitHub Check: CI-builds / builds (ubuntu24,-tap-genai-gcov)
- GitHub Check: CI-builds / builds (debian12,-dbg)
- GitHub Check: CI-builds / builds (ubuntu22,-tap)
- GitHub Check: run / trigger
- GitHub Check: claude-review
🧰 Additional context used
🧠 Learnings (8)
📓 Common learnings
Learnt from: CR
Repo: sysown/proxysql PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-12T11:27:41.142Z
Learning: Refer to `doc/agents/project-conventions.md` for ProxySQL-specific rules on directories, build, test harness, and git workflow
Learnt from: CR
Repo: sysown/proxysql PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-12T11:27:41.142Z
Learning: Applies to **/*.{cpp,h,hpp} : Feature tiers controlled by flags: `PROXYSQL31=1` for v3.1.x (FFTO, TSDB), `PROXYSQLGENAI=1` for v4.0.x (GenAI, MCP, Anomaly Detection). `PROXYSQLGENAI=1` implies `PROXYSQL31=1` which implies `PROXYSQLFFTO=1` and `PROXYSQLTSDB=1`
📚 Learning: 2026-04-12T11:27:41.142Z
Learnt from: CR
Repo: sysown/proxysql PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-12T11:27:41.142Z
Learning: Refer to `doc/agents/project-conventions.md` for ProxySQL-specific rules on directories, build, test harness, and git workflow
Applied to files:
test/infra/infra-dbdeployer-mysql95-binlog/bin/docker-proxy-post.bashtest/infra/infra-dbdeployer-mysql90-binlog/conf/proxysql/infra-config.sqltest/infra/infra-dbdeployer-mysql90-binlog/bin/docker-mysql-post.bashtest/infra/infra-dbdeployer-mysql95-binlog/bin/docker-mysql-post.bashtest/infra/infra-dbdeployer-mysql95-binlog/conf/proxysql/infra-config.sqltest/infra/infra-dbdeployer-mysql90-binlog/bin/docker-proxy-post.bashtest/infra/infra-dbdeployer-mysql90-binlog/.envtest/infra/infra-dbdeployer-mysql95-binlog/.env
📚 Learning: 2026-01-20T09:34:27.165Z
Learnt from: yuji-hatakeyama
Repo: sysown/proxysql PR: 5307
File: test/tap/tests/reg_test_5306-show_warnings_with_comment-t.cpp:39-48
Timestamp: 2026-01-20T09:34:27.165Z
Learning: In ProxySQL test files (test/tap/tests/), resource leaks (such as not calling `mysql_close()` on early return paths) are not typically fixed because test processes are short-lived and the OS frees resources on process exit. This is a common pattern across the test suite.
Applied to files:
test/infra/infra-dbdeployer-mysql95-binlog/bin/docker-proxy-post.bashtest/infra/infra-dbdeployer-mysql95-binlog/conf/proxysql/infra-config.sqltest/infra/infra-dbdeployer-mysql90-binlog/bin/docker-proxy-post.bash
📚 Learning: 2026-04-12T11:27:41.142Z
Learnt from: CR
Repo: sysown/proxysql PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-12T11:27:41.142Z
Learning: Admin Interface implementation resides in `ProxySQL_Admin.cpp` and `Admin_Handler.cpp`, with schema versions tracked in `ProxySQL_Admin_Tables_Definitions.h`. Supports runtime config changes without restart via SQL-based configuration with SQLite3 backend
Applied to files:
test/infra/infra-dbdeployer-mysql95-binlog/bin/docker-proxy-post.bashtest/infra/infra-dbdeployer-mysql90-binlog/conf/proxysql/infra-config.sqltest/infra/infra-dbdeployer-mysql95-binlog/conf/proxysql/infra-config.sqltest/infra/infra-dbdeployer-mysql90-binlog/bin/docker-proxy-post.bash
📚 Learning: 2026-01-20T07:40:34.938Z
Learnt from: yuji-hatakeyama
Repo: sysown/proxysql PR: 5307
File: test/tap/tests/reg_test_5306-show_warnings_with_comment-t.cpp:24-28
Timestamp: 2026-01-20T07:40:34.938Z
Learning: In ProxySQL test files, calling `mysql_error(NULL)` after `mysql_init()` failure is safe because the MariaDB client library implementation returns an empty string for NULL handles (not undefined behavior).
Applied to files:
test/infra/infra-dbdeployer-mysql95-binlog/bin/docker-proxy-post.bashtest/infra/infra-dbdeployer-mysql90-binlog/bin/docker-proxy-post.bash
📚 Learning: 2026-04-01T21:27:03.216Z
Learnt from: wazir-ahmed
Repo: sysown/proxysql PR: 5557
File: test/tap/tests/unit/gtid_set_unit-t.cpp:14-17
Timestamp: 2026-04-01T21:27:03.216Z
Learning: In ProxySQL's unit test directory (test/tap/tests/unit/), test_globals.h and test_init.h are only required for tests that depend on the ProxySQL runtime globals/initialization (i.e., tests that exercise components linked against libproxysql.a). Pure data-structure or utility tests (e.g., ezoption_parser_unit-t.cpp, gtid_set_unit-t.cpp, gtid_trxid_interval_unit-t.cpp) only need tap.h and the relevant project header — omitting test_globals.h and test_init.h is correct and intentional in these cases.
Applied to files:
test/infra/infra-dbdeployer-mysql95-binlog/bin/docker-proxy-post.bashtest/infra/infra-dbdeployer-mysql90-binlog/conf/proxysql/infra-config.sqltest/infra/infra-dbdeployer-mysql95-binlog/conf/proxysql/infra-config.sqltest/infra/infra-dbdeployer-mysql90-binlog/bin/docker-proxy-post.bashtest/infra/infra-dbdeployer-mysql90-binlog/.envtest/infra/infra-dbdeployer-mysql95-binlog/.env
📚 Learning: 2026-04-12T11:27:41.142Z
Learnt from: CR
Repo: sysown/proxysql PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-12T11:27:41.142Z
Learning: Applies to **/*.{cpp,h,hpp} : Feature tiers controlled by flags: `PROXYSQL31=1` for v3.1.x (FFTO, TSDB), `PROXYSQLGENAI=1` for v4.0.x (GenAI, MCP, Anomaly Detection). `PROXYSQLGENAI=1` implies `PROXYSQL31=1` which implies `PROXYSQLFFTO=1` and `PROXYSQLTSDB=1`
Applied to files:
test/infra/infra-dbdeployer-mysql90-binlog/conf/proxysql/infra-config.sqltest/infra/infra-dbdeployer-mysql95-binlog/conf/proxysql/infra-config.sql
📚 Learning: 2026-04-12T11:27:41.142Z
Learnt from: CR
Repo: sysown/proxysql PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-12T11:27:41.142Z
Learning: Applies to **/*.{cpp,h,hpp} : Conditional compilation uses `#ifdef PROXYSQLGENAI`, `#ifdef PROXYSQL31`, `#ifdef PROXYSQLFFTO`, `#ifdef PROXYSQLTSDB`, and `#ifdef PROXYSQLCLICKHOUSE` to gate feature-specific code
Applied to files:
test/infra/infra-dbdeployer-mysql90-binlog/conf/proxysql/infra-config.sqltest/infra/infra-dbdeployer-mysql95-binlog/conf/proxysql/infra-config.sql
🪛 dotenv-linter (4.0.0)
test/infra/infra-dbdeployer-mysql90-binlog/.env
[warning] 6-6: [UnorderedKey] The RHG key should go before the WHG key
(UnorderedKey)
[warning] 7-7: [UnorderedKey] The BHG key should go before the RHG key
(UnorderedKey)
[warning] 8-8: [UnorderedKey] The OHG key should go before the RHG key
(UnorderedKey)
[warning] 26-26: [SubstitutionKey] The INFRA key is not assigned properly
(SubstitutionKey)
[warning] 29-29: [SubstitutionKey] The ROOT_PASSWORD key is not assigned properly
(SubstitutionKey)
[warning] 29-29: [ValueWithoutQuotes] This value needs to be surrounded in quotes
(ValueWithoutQuotes)
[warning] 32-32: [UnorderedKey] The BINLOG_RHG key should go before the BINLOG_WHG key
(UnorderedKey)
[warning] 36-36: [UnorderedKey] The TAP_MYSQL8_BACKEND_HG key should go before the TAP_REG_TEST_3549_AUTOCOMMIT_TRACKING___MYSQL_SERVER_HOSTGROUP key
(UnorderedKey)
test/infra/infra-dbdeployer-mysql95-binlog/.env
[warning] 6-6: [UnorderedKey] The RHG key should go before the WHG key
(UnorderedKey)
[warning] 7-7: [UnorderedKey] The BHG key should go before the RHG key
(UnorderedKey)
[warning] 8-8: [UnorderedKey] The OHG key should go before the RHG key
(UnorderedKey)
[warning] 26-26: [SubstitutionKey] The INFRA key is not assigned properly
(SubstitutionKey)
[warning] 29-29: [SubstitutionKey] The ROOT_PASSWORD key is not assigned properly
(SubstitutionKey)
[warning] 29-29: [ValueWithoutQuotes] This value needs to be surrounded in quotes
(ValueWithoutQuotes)
[warning] 32-32: [UnorderedKey] The BINLOG_RHG key should go before the BINLOG_WHG key
(UnorderedKey)
[warning] 36-36: [UnorderedKey] The TAP_MYSQL8_BACKEND_HG key should go before the TAP_REG_TEST_3549_AUTOCOMMIT_TRACKING___MYSQL_SERVER_HOSTGROUP key
(UnorderedKey)
🪛 Shellcheck (0.11.0)
test/infra/infra-dbdeployer-mysql95-binlog/bin/docker-proxy-post.bash
[info] 5-5: Not following: ./../.env was not specified as input (see shellcheck -x).
(SC1091)
[style] 23-23: Check exit code directly with e.g. 'if mycmd;', not indirectly with $?.
(SC2181)
test/infra/infra-dbdeployer-mysql90-binlog/docker-compose-destroy.bash
[warning] 4-4: Quote this to prevent word splitting.
(SC2046)
[info] 4-4: Double quote to prevent globbing and word splitting.
(SC2086)
[info] 6-6: Not following: .env was not specified as input (see shellcheck -x).
(SC1091)
test/infra/infra-dbdeployer-mysql95-binlog/docker-compose-destroy.bash
[warning] 4-4: Quote this to prevent word splitting.
(SC2046)
[info] 4-4: Double quote to prevent globbing and word splitting.
(SC2086)
[info] 6-6: Not following: .env was not specified as input (see shellcheck -x).
(SC1091)
test/infra/infra-dbdeployer-mysql90-binlog/bin/docker-mysql-post.bash
[info] 4-4: Not following: .env was not specified as input (see shellcheck -x).
(SC1091)
test/infra/infra-dbdeployer-mysql95-binlog/bin/docker-mysql-post.bash
[info] 4-4: Not following: .env was not specified as input (see shellcheck -x).
(SC1091)
test/infra/infra-dbdeployer-mysql90-binlog/docker/entrypoint.sh
[info] 10-10: Use find instead of ls to better handle non-alphanumeric filenames.
(SC2012)
[info] 42-42: Use find instead of ls to better handle non-alphanumeric filenames.
(SC2012)
[info] 62-62: Double quote to prevent globbing and word splitting.
(SC2086)
[info] 82-82: Double quote to prevent globbing and word splitting.
(SC2086)
[info] 155-155: Double quote to prevent globbing and word splitting.
(SC2086)
[info] 156-156: Double quote to prevent globbing and word splitting.
(SC2086)
[info] 157-157: Double quote to prevent globbing and word splitting.
(SC2086)
test/infra/infra-dbdeployer-mysql95-binlog/docker-compose-init.bash
[warning] 4-4: Declare and assign separately to avoid masking return values.
(SC2155)
[warning] 4-4: Quote this to prevent word splitting.
(SC2046)
[warning] 4-4: Quote this to prevent word splitting.
(SC2046)
[warning] 24-24: Quote this to prevent word splitting.
(SC2046)
[info] 24-24: Double quote to prevent globbing and word splitting.
(SC2086)
[warning] 24-24: Expanding an array without an index only gives the first element.
(SC2128)
[warning] 27-27: Quote this to prevent word splitting.
(SC2046)
[info] 27-27: Double quote to prevent globbing and word splitting.
(SC2086)
[info] 33-33: Not following: .env was not specified as input (see shellcheck -x).
(SC1091)
[warning] 48-48: Declare and assign separately to avoid masking return values.
(SC2155)
test/infra/infra-dbdeployer-mysql90-binlog/docker-compose-init.bash
[warning] 4-4: Declare and assign separately to avoid masking return values.
(SC2155)
[warning] 4-4: Quote this to prevent word splitting.
(SC2046)
[warning] 4-4: Quote this to prevent word splitting.
(SC2046)
[warning] 24-24: Quote this to prevent word splitting.
(SC2046)
[info] 24-24: Double quote to prevent globbing and word splitting.
(SC2086)
[warning] 24-24: Expanding an array without an index only gives the first element.
(SC2128)
[warning] 27-27: Quote this to prevent word splitting.
(SC2046)
[info] 27-27: Double quote to prevent globbing and word splitting.
(SC2086)
[info] 33-33: Not following: .env was not specified as input (see shellcheck -x).
(SC1091)
[warning] 48-48: Declare and assign separately to avoid masking return values.
(SC2155)
test/infra/infra-dbdeployer-mysql95-binlog/docker/entrypoint.sh
[info] 10-10: Use find instead of ls to better handle non-alphanumeric filenames.
(SC2012)
[info] 42-42: Use find instead of ls to better handle non-alphanumeric filenames.
(SC2012)
[info] 62-62: Double quote to prevent globbing and word splitting.
(SC2086)
[info] 82-82: Double quote to prevent globbing and word splitting.
(SC2086)
[info] 155-155: Double quote to prevent globbing and word splitting.
(SC2086)
[info] 156-156: Double quote to prevent globbing and word splitting.
(SC2086)
[info] 157-157: Double quote to prevent globbing and word splitting.
(SC2086)
test/infra/infra-dbdeployer-mysql90-binlog/bin/docker-proxy-post.bash
[info] 5-5: Not following: ./../.env was not specified as input (see shellcheck -x).
(SC1091)
[style] 23-23: Check exit code directly with e.g. 'if mycmd;', not indirectly with $?.
(SC2181)
🪛 Trivy (0.69.3)
test/infra/infra-dbdeployer-mysql95-binlog/docker/Dockerfile
[error] 1-1: Image user should not be 'root'
Specify at least 1 USER command in Dockerfile with non-root user as argument
Rule: DS-0002
(IaC/Dockerfile)
test/infra/infra-dbdeployer-mysql90-binlog/docker/Dockerfile
[error] 1-1: Image user should not be 'root'
Specify at least 1 USER command in Dockerfile with non-root user as argument
Rule: DS-0002
(IaC/Dockerfile)
🔇 Additional comments (16)
test/infra/infra-dbdeployer-mysql95-binlog/conf/proxysql/infra-config.sql (1)
1-36: LGTM!The ProxySQL configuration SQL template is well-structured:
- Correctly disables password hashing for admin interface setup
- Uses consistent
${INFRA}comment tagging for cleanup operations- gtid_port values (6020-6022) align with the binlog reader ports defined in entrypoint.sh
- Query rules properly route
SELECT ... FOR UPDATEto writer hostgroup and regularSELECTto reader hostgroup with GTID trackingtest/infra/infra-dbdeployer-mysql95-binlog/docker-compose-destroy.bash (1)
6-11: LGTM!The teardown logic correctly uses the same
COMPOSE_PROJECTnaming convention as the init script and properly removes volumes with-v.test/infra/infra-dbdeployer-mysql95-binlog/.env (1)
1-36: LGTM!The environment configuration correctly defines PREFIX=38 for MySQL 9.5 binlog infrastructure, with derived hostgroup IDs and port mappings. The bash parameter expansion syntax for
INFRAandROOT_PASSWORDdefaults is appropriate since this file is sourced by bash scripts.Note: The static analysis warnings about key ordering and substitution syntax are false positives—key ordering is semantic (WHG before RHG follows writer-before-reader convention), and the bash parameter expansion is intentional.
test/infra/infra-dbdeployer-mysql95-binlog/docker/Dockerfile (2)
1-6: Known limitation: binlog reader authentication with MySQL 9.x.Per the PR description,
proxysql_binlog_readerv2.3 cannot authenticate with MySQL 9.x'scaching_sha2_passwordwithout SSL or public key exchange. This means binlog reader processes will fail to start until either the reader is updated or SSL is configured.Consider adding a comment in the Dockerfile or entrypoint noting this limitation, so future maintainers understand why binlog tests may fail.
8-47: LGTM!The Dockerfile correctly:
- Uses multi-stage build to extract the binlog reader binary
- Installs required MySQL 9.5 runtime dependencies
- Pre-bakes the MySQL tarball to avoid runtime downloads
- Clears reserved-ports to allow the intended base-port configuration
The Trivy warning about root user is acceptable for CI test infrastructure containers.
test/infra/infra-dbdeployer-mysql95-binlog/bin/docker-mysql-post.bash (1)
34-45: LGTM - Correct replication check for binlog infrastructure.The script correctly uses
SHOW REPLICA STATUSfor standard MySQL replication verification (as opposed to Group Replication'sperformance_schema.replication_group_members), which is appropriate for this binlog-based topology.test/infra/infra-dbdeployer-mysql95-binlog/docker/entrypoint.sh (2)
140-176: Binlog reader startup with expected authentication failure.The script correctly handles the known limitation where
proxysql_binlog_readerv2.3 cannot authenticate with MySQL 9.x'scaching_sha2_password. The WARNING on line 169 allows the container to continue even when readers fail to start, which is appropriate given this is a known issue awaiting a reader update or SSL wrapper.
74-131: LGTM - User provisioning logic.The user creation with
SQL_LOG_BIN=0correctly prevents replication of these admin operations. The loop for sbtest users using command substitution is a practical approach for generating the required grants.test/infra/infra-dbdeployer-mysql95-binlog/docker-compose-init.bash (1)
57-149: LGTM - Core initialization logic.The script properly:
- Checks for existing running containers before proceeding
- Creates required directories with appropriate permissions
- Uses isolated env files for docker-compose
- Verifies container health after startup
- Waits for the dbdeployer readiness marker with timeout
- Runs optional post-scripts for additional configuration
test/infra/infra-dbdeployer-mysql95-binlog/bin/docker-proxy-post.bash (1)
7-7:⚠️ Potential issue | 🔴 CriticalThe ProxySQL service is missing from docker-compose.yml.
The script references
PROXY_CONTAINER="proxysql.${INFRA_ID}"on line 7, but the docker-compose.yml file for this infrastructure does not define a proxysql service. This will cause thedocker execcommand on line 11 to fail with a "container not found" error. Either add the proxysql service definition to docker-compose.yml or remove this post-configuration script if ProxySQL is not required for this binlog infrastructure.⛔ Skipped due to learnings
Learnt from: CR Repo: sysown/proxysql PR: 0 File: CLAUDE.md:0-0 Timestamp: 2026-04-12T11:27:41.142Z Learning: Refer to `doc/agents/project-conventions.md` for ProxySQL-specific rules on directories, build, test harness, and git workflowLearnt from: yuji-hatakeyama Repo: sysown/proxysql PR: 5307 File: test/tap/tests/reg_test_5306-show_warnings_with_comment-t.cpp:39-48 Timestamp: 2026-01-20T09:34:27.165Z Learning: In ProxySQL test files (test/tap/tests/), resource leaks (such as not calling `mysql_close()` on early return paths) are not typically fixed because test processes are short-lived and the OS frees resources on process exit. This is a common pattern across the test suite.test/infra/infra-dbdeployer-mysql90-binlog/.env (1)
1-36: Looks good: hostgroup/port derivation and TAP exports are coherent.This aligns with the PREFIX-based convention and keeps downstream TAP variables explicit.
test/infra/infra-dbdeployer-mysql90-binlog/docker-compose.yml (1)
3-23: Compose service/network wiring is consistent with init/post hooks.
container_name, aliases, and${INFRA_ID}_backendusage line up correctly with the related scripts.test/infra/infra-dbdeployer-mysql90-binlog/docker/entrypoint.sh (4)
1-16: LGTM!Good defensive scripting with
set -eandset -o pipefail. Thelsusage is acceptable in this controlled Docker context with predictable tarball naming.
39-72: LGTM!The node readiness wait logic with proper timeout handling (60 seconds per node with hard exit on failure) is well implemented. The unquoted
${MYSQL_CMD}is intentional for word splitting during command execution.
74-138: LGTM!The user provisioning logic is correct: connecting with dbdeployer's default password (
msandbox), then altering to the configuredROOT_PASSWORDwithSQL_LOG_BIN=0to avoid replicating credentials (allowing independent per-node setup). The subsequentread_onlyconfiguration correctly uses the new password.
178-189: LGTM!Standard readiness signaling pattern with clear port documentation in the output. Using
exec sleep infinityproperly replaces the shell process.
| if [ "${IO_RUNNING}" = "Yes" ] && [ "${SQL_RUNNING}" = "Yes" ]; then | ||
| echo " OK (IO: Yes, SQL: Yes)" | ||
| else | ||
| echo " WARNING (IO: ${IO_RUNNING}, SQL: ${SQL_RUNNING})" | ||
| fi |
There was a problem hiding this comment.
Replication readiness check should fail fast.
Line 43 only logs a warning when replication threads are not running, so the suite can continue with a broken cluster.
Suggested fix
if [ "${IO_RUNNING}" = "Yes" ] && [ "${SQL_RUNNING}" = "Yes" ]; then
echo " OK (IO: Yes, SQL: Yes)"
else
- echo " WARNING (IO: ${IO_RUNNING}, SQL: ${SQL_RUNNING})"
+ echo " FAILED (IO: ${IO_RUNNING}, SQL: ${SQL_RUNNING})"
+ exit 1
fi
done🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/infra/infra-dbdeployer-mysql90-binlog/bin/docker-mysql-post.bash` around
lines 40 - 44, The replication readiness check currently only logs a warning
when IO_RUNNING or SQL_RUNNING are not "Yes" (variables IO_RUNNING and
SQL_RUNNING) so the suite continues; change the else branch in that conditional
(the block that echoes " WARNING (IO: ${IO_RUNNING}, SQL: ${SQL_RUNNING})") to
print a clear error message and exit with a non‑zero status (e.g., exit 1) to
fail fast when replication threads are not running.
| docker exec -i "${PROXY_CONTAINER}" mysql -uradmin -pradmin -h127.0.0.1 -P6032 <<SQL | ||
| $(eval "echo \"$(cat ./conf/proxysql/infra-config.sql)\"") | ||
|
|
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, locate the file and verify it exists
find . -type f -name "docker-proxy-post.bash" | head -20Repository: sysown/proxysql
Length of output: 1360
🏁 Script executed:
# Check the structure around the specified file path
git ls-files test/infra/infra-dbdeployer-mysql90-binlog/bin/ 2>/dev/null | head -20Repository: sysown/proxysql
Length of output: 198
🏁 Script executed:
# Read the file to verify the code snippet
if [ -f "test/infra/infra-dbdeployer-mysql90-binlog/bin/docker-proxy-post.bash" ]; then
echo "=== File content (with line numbers) ===" && \
cat -n "test/infra/infra-dbdeployer-mysql90-binlog/bin/docker-proxy-post.bash" | head -50
else
echo "File not found at specified path"
fiRepository: sysown/proxysql
Length of output: 1180
🏁 Script executed:
# Search for SCRIPT_DIR and PROXY_CONTAINER usage patterns
rg "SCRIPT_DIR|PROXY_CONTAINER" test/infra/infra-dbdeployer-mysql90-binlog/ -A 2 -B 2 2>/dev/null || echo "Pattern not found or directory doesn't exist"Repository: sysown/proxysql
Length of output: 2671
🏁 Script executed:
# Check for envsubst usage in the repository
rg "envsubst" . --type bash 2>/dev/null | head -10Repository: sysown/proxysql
Length of output: 41
🏁 Script executed:
# Look for the infra-config.sql file referenced in the code
find . -type f -name "infra-config.sql" 2>/dev/nullRepository: sysown/proxysql
Length of output: 1560
🏁 Script executed:
# Read the infra-config.sql to see what variables it contains
cat "test/infra/infra-dbdeployer-mysql90-binlog/conf/proxysql/infra-config.sql"Repository: sysown/proxysql
Length of output: 3444
🏁 Script executed:
# Check the working directory context - where is the script executed from?
rg "docker-proxy-post.bash" . --type bash -B 2 -A 2 2>/dev/null | head -40Repository: sysown/proxysql
Length of output: 41
🏁 Script executed:
# Check what's in the .env file to understand the actual variables
find test/infra/infra-dbdeployer-mysql90-binlog -name ".env" -exec cat {} \;Repository: sysown/proxysql
Length of output: 872
🏁 Script executed:
# Verify the Dockerfile to see if envsubst is available
find test/infra/infra-dbdeployer-mysql90-binlog -name "Dockerfile" -exec cat {} \;Repository: sysown/proxysql
Length of output: 1811
🏁 Script executed:
# Check if there are other similar scripts that handle this differently
rg "infra-config.sql" . --type bash -B 3 -A 3 2>/dev/null | head -60Repository: sysown/proxysql
Length of output: 41
🏁 Script executed:
# Check if there are other ways templating is handled in similar scripts
rg "cat.*conf" test/infra --type bash | head -20Repository: sysown/proxysql
Length of output: 87
🏁 Script executed:
# Check if gettext or envsubst is mentioned anywhere in build scripts
rg "gettext|envsubst" test/infra/ --type bash --type dockerfileRepository: sysown/proxysql
Length of output: 87
🏁 Script executed:
# Look for any safe variable substitution patterns used elsewhere
rg "sed.*-e.*\$" test/infra --type bash -A 1 -B 1 | head -30Repository: sysown/proxysql
Length of output: 87
🏁 Script executed:
# Check docker-compose or other CI configs to see how these scripts are invoked
find test/infra/infra-dbdeployer-mysql90-binlog -type f \( -name "docker-compose*" -o -name "*.yaml" -o -name "*.yml" \) -exec cat {} \;Repository: sysown/proxysql
Length of output: 6493
🏁 Script executed:
# Check if there are any build-time package installations or setup scripts
find test/infra/infra-dbdeployer-mysql90-binlog -name "*.sh" -o -name "Dockerfile*" | xargs ls -laRepository: sysown/proxysql
Length of output: 389
🏁 Script executed:
# Look for any existing safe templating patterns in other similar scripts
rg "echo.*\$\{" test/infra --type bash -B 2 -A 2 | head -40Repository: sysown/proxysql
Length of output: 87
🏁 Script executed:
# Check what's in docker/entrypoint.sh to understand the runtime environment
cat test/infra/infra-dbdeployer-mysql90-binlog/docker/entrypoint.shRepository: sysown/proxysql
Length of output: 6405
🏁 Script executed:
# Look for alternative safe template substitution methods in the codebase
find test/infra -name "*.bash" -o -name "*.sh" | head -5 | xargs grep -l "sed.*echo" 2>/dev/nullRepository: sysown/proxysql
Length of output: 43
🏁 Script executed:
# Check if there's a pattern of using sed for safe substitution
rg "sed.*\\\$" test/infra -A 2 -B 2 2>/dev/null | head -50Repository: sysown/proxysql
Length of output: 5052
Replace eval SQL templating with safe variable substitution.
Line 12 uses eval to expand the SQL template, which executes any shell syntax in the substituted variables. If ROOT_PASSWORD or INFRA contains shell metacharacters (e.g., $()), it will be executed on the host.
Use a safe substitution method like envsubst instead. Also fix the working-directory-relative path (./conf/...) to be script-relative using SCRIPT_DIR.
Suggested fix
docker exec -i "${PROXY_CONTAINER}" mysql -uradmin -pradmin -h127.0.0.1 -P6032 <<SQL
-$(eval "echo \"$(cat ./conf/proxysql/infra-config.sql)\"")
+$(envsubst '${INFRA},${WHG},${RHG},${PREFIX},${ROOT_PASSWORD}' < "${SCRIPT_DIR}/../conf/proxysql/infra-config.sql")Note: Ensure gettext package is available in the Docker image, or use sed for substitution if preferred.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/infra/infra-dbdeployer-mysql90-binlog/bin/docker-proxy-post.bash` around
lines 11 - 13, Replace the unsafe eval-based SQL templating in the docker exec
invocation by using envsubst and a script-relative path: avoid using eval on
"$(cat ./conf/proxysql/infra-config.sql)" and instead read the template from
SCRIPT_DIR/conf/proxysql/infra-config.sql, pipe it through envsubst (exporting
variables such as ROOT_PASSWORD and INFRA) and feed the result into the same
docker exec mysql command that uses PROXY_CONTAINER; ensure SCRIPT_DIR is
computed (e.g., from ${BASH_SOURCE[0]}) and required env vars are exported
before calling envsubst so no shell evaluation of template content occurs.
|
|
||
| DELETE FROM mysql_replication_hostgroups WHERE comment LIKE '%${INFRA}'; | ||
| DELETE FROM mysql_replication_hostgroups WHERE writer_hostgroup=${WHG} AND reader_hostgroup=${RHG}; | ||
| DELETE FROM mysql_replication_hostgroups WHERE comment='.' OR comment='' OR comment IS NULL; |
There was a problem hiding this comment.
Avoid non-scoped deletion in replication hostgroups.
Line 14 deletes rows globally (comment='.' OR comment='' OR comment IS NULL), not just rows owned by this infra. In shared test topologies, this can wipe unrelated mappings.
Suggested fix
-DELETE FROM mysql_replication_hostgroups WHERE comment='.' OR comment='' OR comment IS NULL;
+-- Keep cleanup scoped to this infra only (already covered by previous DELETEs)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| DELETE FROM mysql_replication_hostgroups WHERE comment='.' OR comment='' OR comment IS NULL; | |
| -- Keep cleanup scoped to this infra only (already covered by previous DELETEs) |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/infra/infra-dbdeployer-mysql90-binlog/conf/proxysql/infra-config.sql` at
line 14, The DELETE in mysql_replication_hostgroups is unscoped and removes rows
across the whole cluster (it targets comment='.' OR comment='' OR comment IS
NULL); change it to only remove rows owned by this infra by adding a restrictive
WHERE clause that targets your infra's identifier (for example WHERE comment
LIKE 'infra:%' or WHERE comment = '<your_infra_id>') or by restricting to
specific hostgroup IDs/cluster identifiers used by this deployment; update the
statement operating on mysql_replication_hostgroups and the comment column so it
only affects rows belonging to this infra.
| export INFRA=${PWD##*/} | ||
| export COMPOSE_PROJECT="${INFRA}-${INFRA_ID}" | ||
|
|
||
| echo "Destroying CI Infra Cluster '${INFRA}' (Project: ${COMPOSE_PROJECT})..." | ||
| docker compose -p "${COMPOSE_PROJECT}" down -v |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Read the full destroy script to see all context
cat -n "test/infra/infra-dbdeployer-mysql90-binlog/docker-compose-destroy.bash"Repository: sysown/proxysql
Length of output: 451
🏁 Script executed:
# Look for the corresponding init script to compare approaches
fd "docker-compose-init" "test/infra/infra-dbdeployer-mysql90-binlog/"Repository: sysown/proxysql
Length of output: 126
🏁 Script executed:
# Search for other destroy scripts to see patterns
fd "docker-compose-destroy" "test/infra/" -x cat -n {}Repository: sysown/proxysql
Length of output: 14720
🏁 Script executed:
# Check if there's a sample .env or documentation about INFRA_ID requirement
fd ".env" "test/infra/infra-dbdeployer-mysql90-binlog/" -x cat {}Repository: sysown/proxysql
Length of output: 41
🏁 Script executed:
# Search for INFRA_ID documentation or setup instructions
fd -e md -e txt "test/infra/" -x grep -l "INFRA_ID" {}Repository: sysown/proxysql
Length of output: 408
🏁 Script executed:
# Check if other similar scripts validate INFRA_ID before using it
rg "INFRA_ID" "test/infra/" -A 3 -B 3 | grep -E "(if|INFRA_ID|error|Error)" | head -40Repository: sysown/proxysql
Length of output: 4180
Add INFRA_ID validation and docker compose CLI fallback to prevent cleanup failures.
Line 8 builds COMPOSE_PROJECT from INFRA_ID without checking if it's set, resulting in a malformed project name if .env lacks this variable. Line 11 hardcodes docker compose which fails in environments running only docker-compose. More robust patterns exist elsewhere in the codebase (e.g., infra-pgsql17-repl) and should be applied here.
Suggested fix
set -a; . .env; set +a
export INFRA=${PWD##*/}
+if [ -z "${INFRA_ID}" ]; then
+ echo "Error: INFRA_ID must be set"
+ exit 1
+fi
export COMPOSE_PROJECT="${INFRA}-${INFRA_ID}"
+
+COMPOSE_CMD="docker compose"
+if ! $COMPOSE_CMD version &>/dev/null; then
+ COMPOSE_CMD="docker-compose"
+fi
echo "Destroying CI Infra Cluster '${INFRA}' (Project: ${COMPOSE_PROJECT})..."
-docker compose -p "${COMPOSE_PROJECT}" down -v
+$COMPOSE_CMD -p "${COMPOSE_PROJECT}" down -v📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| export INFRA=${PWD##*/} | |
| export COMPOSE_PROJECT="${INFRA}-${INFRA_ID}" | |
| echo "Destroying CI Infra Cluster '${INFRA}' (Project: ${COMPOSE_PROJECT})..." | |
| docker compose -p "${COMPOSE_PROJECT}" down -v | |
| export INFRA=${PWD##*/} | |
| if [ -z "${INFRA_ID}" ]; then | |
| echo "Error: INFRA_ID must be set" | |
| exit 1 | |
| fi | |
| export COMPOSE_PROJECT="${INFRA}-${INFRA_ID}" | |
| COMPOSE_CMD="docker compose" | |
| if ! $COMPOSE_CMD version &>/dev/null; then | |
| COMPOSE_CMD="docker-compose" | |
| fi | |
| echo "Destroying CI Infra Cluster '${INFRA}' (Project: ${COMPOSE_PROJECT})..." | |
| $COMPOSE_CMD -p "${COMPOSE_PROJECT}" down -v |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/infra/infra-dbdeployer-mysql90-binlog/docker-compose-destroy.bash`
around lines 7 - 11, Validate INFRA_ID before constructing COMPOSE_PROJECT and
add a docker CLI fallback: check that INFRA_ID is non-empty and exit with a
clear error if it is unset (so COMPOSE_PROJECT="${INFRA}-${INFRA_ID}" is never
constructed from an empty INFRA_ID), and replace the hardcoded "docker compose
-p \"${COMPOSE_PROJECT}\" down -v" call with logic that detects whether the
system provides the `docker compose` subcommand or only the legacy
`docker-compose` binary and invokes the available one accordingly; update the
symbols INFRA_ID, COMPOSE_PROJECT and the down invocation to use the chosen CLI.
| if [ -z "${INFRA_ID}" ]; then | ||
| export INFRA_ID=$(basename $(dirname $(pwd)) | sed 's/infra-//; s/docker-//') | ||
| fi |
There was a problem hiding this comment.
INFRA_ID derivation is caller-CWD dependent.
Line 4 uses $(pwd) before switching to the script directory, so running the script from a different location can compute the wrong project/network identity.
Suggested fix
-if [ -z "${INFRA_ID}" ]; then
- export INFRA_ID=$(basename $(dirname $(pwd)) | sed 's/infra-//; s/docker-//')
-fi
+if [ -z "${INFRA_ID}" ]; then
+ export INFRA_ID="$(basename "$(dirname "${SCRIPT_DIR}")" | sed 's/^infra-//; s/^docker-//')"
+fi🧰 Tools
🪛 Shellcheck (0.11.0)
[warning] 4-4: Declare and assign separately to avoid masking return values.
(SC2155)
[warning] 4-4: Quote this to prevent word splitting.
(SC2046)
[warning] 4-4: Quote this to prevent word splitting.
(SC2046)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/infra/infra-dbdeployer-mysql90-binlog/docker-compose-init.bash` around
lines 3 - 5, The INFRA_ID derivation uses $(pwd) which is caller-CWD dependent;
change it to compute the project directory from the script's own location
instead (use the script directory via dirname "$0" or BASH_SOURCE and cd there
before deriving the basename), then apply the same sed transformations; update
the export INFRA_ID assignment (the symbol INFRA_ID) so it uses the
script-resolved path rather than $(pwd) to ensure a consistent network identity
regardless of where the script is invoked.
| ENVEOF | ||
|
|
||
| # 4. START CONTAINERS | ||
| if ! $COMPOSE_CMD --env-file .env --env-file "${ENV_FILE}" -p "${COMPOSE_PROJECT}" up -d; then |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
for cmd in "docker compose" "docker-compose"; do
bin="${cmd%% *}"
if command -v "$bin" >/dev/null 2>&1; then
echo "== ${cmd} =="
$cmd --help | grep -n -- '--env-file' || true
fi
doneRepository: sysown/proxysql
Length of output: 41
🏁 Script executed:
cat -n test/infra/infra-dbdeployer-mysql90-binlog/docker-compose-init.bash | sed -n '100,112p'Repository: sysown/proxysql
Length of output: 537
🌐 Web query:
docker-compose multiple --env-file arguments support legacy version 1.29
💡 Result:
No, docker-compose version 1.29 (legacy Python v1) does not support multiple --env-file arguments. The --env-file flag accepts only a single file path. Multiple arguments were not supported until Docker Compose v2.17.0 (Go implementation), implemented via PRs like #10284 after issues #7326 and #7847 requested the feature. In v1.29, changelogs show no such addition, and docs describe it as singular "an alternate environment file". Users reported it overriding previous files or failing, requiring workarounds like merging files manually or using stdin hacks. Note: service-level env_file: in compose.yaml has long supported arrays for container env vars, but that's distinct from CLI --env-file for project interpolation.
Citations:
- 1: Support multiple .env files docker/compose#7326
- 2: Multiple --env-file? docker/compose#7847
- 3: Support multiple .env files docker/compose#7326
- 4: Multiple --env-file cli arguments not be merged correctly, if it's an environment or args configuration option docker/compose#9166
- 5: https://docs.docker.com/v1.11/compose/reference/
- 6: https://docs.docker.com/compose/env-file/
- 7: https://github.com/docker/compose/blob/v1/CHANGELOG.md
- 8: https://github.com/docker/compose/blob/master/CHANGELOG.md
- 9: https://github.com/docker/compose/releases/tag/1.29.0
- 10: https://docs.docker.com/compose/reference/docker-compose/
🌐 Web query:
docker compose vs docker-compose --env-file multiple files differences
💡 Result:
docker compose (v2, space-separated) and docker-compose (v1, hyphenated) both support --env-file for specifying alternate environment files for variable interpolation in the Compose file (e.g., ${VAR}). The key differences and handling of multiple files are: - docker-compose (v1): Supports a single --env-file flag. Multiple files require workarounds like shell concatenation (e.g., --env-file <(cat .env .env.local)). Deprecated; use docker compose instead. - docker compose (v2): Supports multiple --env-file flags directly (since v2.17+), loading files in order with later files overriding earlier ones. Example: docker compose --env-file .env --env-file .env.override up. If no --env-file, loads .env from working directory by default. Both automatically load .env (if present) for interpolation unless overridden by --env-file. These vars are for Compose file substitution, not container injection (use env_file: in YAML for that, which supports lists in both). Other v1 vs v2 differences include: v2 is a Docker CLI plugin (Go-based, faster), uses compose.yaml (but supports docker-compose.yaml), better integration, new features like profiles; v1 is legacy Python tool. Precedence (highest to lowest): shell env > --env-file(s) or default .env > Compose file .env file attr.
Citations:
- 1: https://docs.docker.com/compose/env-file/
- 2: https://docs.docker.com/compose/environment-variables/env-file/
- 3: https://docs.docker.com/compose/reference/
- 4: https://stackoverflow.com/questions/62728192/how-to-specify-multiple-env-files-for-a-docker-compose-service
- 5: https://stackoverflow.com/questions/66514436/difference-between-docker-compose-and-docker-compose
- 6: https://devops-daily.com/posts/docker-compose-vs-docker-compose
docker-compose fallback does not support multiple --env-file arguments.
Line 106 passes two --env-file arguments. This syntax is supported on modern docker compose (v2.17+) but not on the legacy docker-compose (v1.x) tool. If the system lacks the Docker v2 plugin and falls back to docker-compose, this command will fail because the legacy version only accepts a single --env-file flag—multiple arguments are not recognized. Consider merging environment files or adding a version check before execution.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/infra/infra-dbdeployer-mysql90-binlog/docker-compose-init.bash` at line
106, The current invocation using COMPOSE_CMD with two --env-file args can break
when COMPOSE_CMD is the legacy docker-compose; detect whether COMPOSE_CMD is
legacy (e.g., check if "$COMPOSE_CMD" name equals "docker-compose" or parse
"$COMPOSE_CMD version" output) and if so merge .env and "${ENV_FILE}" into a
temporary combined env file (ensure proper key precedence and cleanup) and call
$COMPOSE_CMD with a single --env-file pointing to that temp file; otherwise
(modern docker compose) keep the two --env-file arguments as-is. Reference:
COMPOSE_CMD, ENV_FILE, .env, COMPOSE_PROJECT and the existing up -d invocation.
| # Install dbdeployer | ||
| RUN curl -fsSL "https://github.com/ProxySQL/dbdeployer/releases/download/v${DBDEPLOYER_VERSION}/dbdeployer-${DBDEPLOYER_VERSION}.linux_amd64.tar.gz" \ | ||
| | tar -xz -C /usr/local/bin/ \ | ||
| && chmod +x /usr/local/bin/dbdeployer |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -name "Dockerfile" -path "*dbdeployer*" | head -20Repository: sysown/proxysql
Length of output: 884
🏁 Script executed:
git ls-files | grep -i dockerfile | grep -i dbdeployerRepository: sysown/proxysql
Length of output: 856
🏁 Script executed:
cat -n test/infra/infra-dbdeployer-mysql90-binlog/docker/DockerfileRepository: sysown/proxysql
Length of output: 2140
🌐 Web query:
dbdeployer releases github checksums SHA256
💡 Result:
dbdeployer releases on GitHub provide SHA256 checksum files for verifying downloads. The original repository (datacharmer/dbdeployer) is archived since Oct 29, 2023, with latest release v1.73.0 (Jul 9, 2023). It mentions continuation at ProxySQL, but no active ProxySQL/dbdeployer repo found in searches. Development may have moved, but releases are read-only. For v1.73.0 (latest), assets include: - dbdeployer-1.73.0.linux.tar.gz.sha256 (SHA256 checksum for Linux tar.gz) - dbdeployer-1.73.0.linux.sha256 - dbdeployer-1.73.0.osx.tar.gz.sha256 (SHA256 for OSX tar.gz) - dbdeployer-1.73.0.osx.sha256 - Similar for docs versions: dbdeployer-1.73.0-docs.linux.tar.gz.sha256, etc. To verify: download the .tar.gz and matching .sha256 file from https://github.com/datacharmer/dbdeployer/releases/tag/v1.73.0, then run sha256sum -c dbdeployer-1.73.0.linux.tar.gz.sha256. All releases (102 total) follow similar pattern with platform-specific .tar.gz and .sha256 files. Repository last push 2026-04-07, but no new tagged releases post-2023. ProxySQL blog mentions dbdeployer v2.1.1 with install script from raw.githubusercontent.com/ProxySQL/dbdeployer/master/scripts/dbdeployer-install.sh, suggesting a fork/repo exists, but not found in searches. Use original releases for checksums.
Citations:
- 1: https://github.com/datacharmer/dbdeployer/releases/tag/v1.73.0
- 2: https://github.com/datacharmer/dbdeployer/releases
- 3: https://github.com/datacharmer/dbdeployer/releases/latest
- 4: https://github.com/datacharmer/dbdeployer
- 5: https://proxysql.com/blog/proxysql-dbdeployer-whats-coming
🏁 Script executed:
# Check other dbdeployer Dockerfiles to see if any use checksums
grep -r "dbdeployer" test/infra/*/docker/Dockerfile | grep -i "sha256\|checksum" | head -10Repository: sysown/proxysql
Length of output: 41
🌐 Web query:
ProxySQL/dbdeployer v2.2.1 release checksums
💡 Result:
No checksums for ProxySQL/dbdeployer v2.2.1 release were found in available sources. The original dbdeployer project (datacharmer/dbdeployer) is archived with latest v1.73.0 (2023). ProxySQL took over dbdeployer, mentioning v2.1.1 in blog posts (proxysql.com/blog), with install script at raw.githubusercontent.com/ProxySQL/dbdeployer/master/scripts/dbdeployer-install.sh, but no GitHub repo or v2.2.1 release page with checksums located. Check official ProxySQL site or repo directly for latest.
Citations:
- 1: https://github.com/datacharmer/dbdeployer
- 2: https://proxysql.com/blog/proxysql-dbdeployer-whats-coming/
- 3: https://proxysql.com/blog/proxysql-dbdeployer-whats-coming
🌐 Web query:
site:github.com ProxySQL dbdeployer releases
💡 Result:
dbdeployer original repository (datacharmer/dbdeployer) is archived with latest release v1.73.0 on 2023-07-09. It states "dbdeployer continues at ProxySQL. See the announcement." The ProxySQL GitHub organization (github.com/ProxySQL) lists a dbdeployer repository described as "DBdeployer is a tool that deploys MySQL database servers easily." with last update 2026-04-06, indicating active maintenance under ProxySQL. No specific releases listed for the ProxySQL fork in search results, but commits continue post-archival. Original CHANGELOG up to 1.73.0. ProxySQL itself has releases up to v4.0.6 prerelease (2026-03-10) and v3.0.4 (2025-12-22), but these are for the proxy, not dbdeployer.
Citations:
- 1: https://github.com/datacharmer/dbdeployer/releases/tag/v1.73.0
- 2: https://github.com/datacharmer/dbdeployer/blob/master/CHANGELOG.md
- 3: https://github.com/datacharmer/dbdeployer
- 4: https://github.com/ProxySQL
🏁 Script executed:
# Check git history to see if ProxySQL fork exists and check for recent changes
git remote -v 2>/dev/null || echo "No remotes"Repository: sysown/proxysql
Length of output: 177
Verify dbdeployer download integrity with available checksums.
Lines 25-27 download and execute dbdeployer without integrity verification. While the original dbdeployer project publishes SHA256 checksums, the ProxySQL fork's release assets are unclear. Recommend checking the ProxySQL/dbdeployer releases page for checksums; if available, add validation as suggested. If not, document the pinned version or consider alternative mitigation.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/infra/infra-dbdeployer-mysql90-binlog/docker/Dockerfile` around lines 24
- 27, The Dockerfile currently downloads and extracts dbdeployer in the RUN step
using DBDEPLOYER_VERSION without verifying integrity; update the RUN sequence
that references DBDEPLOYER_VERSION and /usr/local/bin/dbdeployer to first fetch
the published checksum (or signature) from the ProxySQL/dbdeployer release
assets (e.g., .sha256 or .asc), verify the downloaded tarball against that
checksum (using sha256sum -c or gpg --verify) and only extract on success, and
if no checksum/signature is published add a clear comment documenting the pinned
DBDEPLOYER_VERSION and the lack of published checksums and/or consider switching
to a verified upstream or embedding a known-good checksum variable for
reproducible builds.
| for i in 0 1 2; do | ||
| READER_PORT="${READER_PORTS[$i]}" | ||
| echo -n " Checking reader on port ${READER_PORT}..." | ||
| MAX_WAIT=10 | ||
| COUNT=0 | ||
| while ! bash -c "echo > /dev/tcp/127.0.0.1/${READER_PORT}" 2>/dev/null; do | ||
| if [ $COUNT -ge $MAX_WAIT ]; then | ||
| echo " WARNING: reader on port ${READER_PORT} not responding (continuing anyway)" | ||
| break | ||
| fi | ||
| sleep 1 | ||
| COUNT=$((COUNT + 1)) | ||
| done | ||
| echo " OK" | ||
| done |
There was a problem hiding this comment.
Fix misleading output: "OK" is printed even after timeout warning.
When the reader port check times out, the script prints "WARNING: reader on port X not responding" but then unconditionally prints " OK" on line 175 after breaking out of the loop. This produces confusing output like WARNING: ... OK.
Proposed fix
for i in 0 1 2; do
READER_PORT="${READER_PORTS[$i]}"
echo -n " Checking reader on port ${READER_PORT}..."
MAX_WAIT=10
COUNT=0
while ! bash -c "echo > /dev/tcp/127.0.0.1/${READER_PORT}" 2>/dev/null; do
if [ $COUNT -ge $MAX_WAIT ]; then
echo " WARNING: reader on port ${READER_PORT} not responding (continuing anyway)"
- break
+ continue 2
fi
sleep 1
COUNT=$((COUNT + 1))
done
echo " OK"
doneAlternatively, use a success flag:
Alternative fix with flag
for i in 0 1 2; do
READER_PORT="${READER_PORTS[$i]}"
echo -n " Checking reader on port ${READER_PORT}..."
MAX_WAIT=10
COUNT=0
+ READER_OK=0
while ! bash -c "echo > /dev/tcp/127.0.0.1/${READER_PORT}" 2>/dev/null; do
if [ $COUNT -ge $MAX_WAIT ]; then
echo " WARNING: reader on port ${READER_PORT} not responding (continuing anyway)"
break
fi
sleep 1
COUNT=$((COUNT + 1))
done
- echo " OK"
+ if [ $COUNT -lt $MAX_WAIT ]; then
+ echo " OK"
+ fi
done📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| for i in 0 1 2; do | |
| READER_PORT="${READER_PORTS[$i]}" | |
| echo -n " Checking reader on port ${READER_PORT}..." | |
| MAX_WAIT=10 | |
| COUNT=0 | |
| while ! bash -c "echo > /dev/tcp/127.0.0.1/${READER_PORT}" 2>/dev/null; do | |
| if [ $COUNT -ge $MAX_WAIT ]; then | |
| echo " WARNING: reader on port ${READER_PORT} not responding (continuing anyway)" | |
| break | |
| fi | |
| sleep 1 | |
| COUNT=$((COUNT + 1)) | |
| done | |
| echo " OK" | |
| done | |
| for i in 0 1 2; do | |
| READER_PORT="${READER_PORTS[$i]}" | |
| echo -n " Checking reader on port ${READER_PORT}..." | |
| MAX_WAIT=10 | |
| COUNT=0 | |
| while ! bash -c "echo > /dev/tcp/127.0.0.1/${READER_PORT}" 2>/dev/null; do | |
| if [ $COUNT -ge $MAX_WAIT ]; then | |
| echo " WARNING: reader on port ${READER_PORT} not responding (continuing anyway)" | |
| continue 2 | |
| fi | |
| sleep 1 | |
| COUNT=$((COUNT + 1)) | |
| done | |
| echo " OK" | |
| done |
| for i in 0 1 2; do | |
| READER_PORT="${READER_PORTS[$i]}" | |
| echo -n " Checking reader on port ${READER_PORT}..." | |
| MAX_WAIT=10 | |
| COUNT=0 | |
| while ! bash -c "echo > /dev/tcp/127.0.0.1/${READER_PORT}" 2>/dev/null; do | |
| if [ $COUNT -ge $MAX_WAIT ]; then | |
| echo " WARNING: reader on port ${READER_PORT} not responding (continuing anyway)" | |
| break | |
| fi | |
| sleep 1 | |
| COUNT=$((COUNT + 1)) | |
| done | |
| echo " OK" | |
| done | |
| for i in 0 1 2; do | |
| READER_PORT="${READER_PORTS[$i]}" | |
| echo -n " Checking reader on port ${READER_PORT}..." | |
| MAX_WAIT=10 | |
| COUNT=0 | |
| while ! bash -c "echo > /dev/tcp/127.0.0.1/${READER_PORT}" 2>/dev/null; do | |
| if [ $COUNT -ge $MAX_WAIT ]; then | |
| echo " WARNING: reader on port ${READER_PORT} not responding (continuing anyway)" | |
| break | |
| fi | |
| sleep 1 | |
| COUNT=$((COUNT + 1)) | |
| done | |
| if [ $COUNT -lt $MAX_WAIT ]; then | |
| echo " OK" | |
| fi | |
| done |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/infra/infra-dbdeployer-mysql90-binlog/docker/entrypoint.sh` around lines
162 - 176, The loop that checks reader ports prints " OK" unconditionally even
after a timeout; update the loop around READER_PORT/READER_PORTS so that success
is detected and " OK" is printed only when the TCP connection succeeds:
introduce a success flag (e.g., SUCCESS=0 before the while), set SUCCESS=1 if
the bash -c connection succeeds (or set after the while only if COUNT <
MAX_WAIT), and after the loop echo " OK" only when SUCCESS is true; otherwise
leave the warning as-is (do not print " OK" after the timeout).
| fi | ||
| fi | ||
| done | ||
| [ -f "${DB_BUNDLE}" ] && sudo chmod 666 "${DB_BUNDLE}" "${CA_BUNDLE}" || true |
There was a problem hiding this comment.
Potential issue if CA_BUNDLE wasn't created.
If ${DB_BUNDLE} exists but ${CA_BUNDLE} doesn't (e.g., due to a partial failure in the cert collection loop), the chmod command will fail. Consider checking both files or using separate conditionals.
🔧 Suggested fix
-[ -f "${DB_BUNDLE}" ] && sudo chmod 666 "${DB_BUNDLE}" "${CA_BUNDLE}" || true
+[ -f "${DB_BUNDLE}" ] && sudo chmod 666 "${DB_BUNDLE}" || true
+[ -f "${CA_BUNDLE}" ] && sudo chmod 666 "${CA_BUNDLE}" || true📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| [ -f "${DB_BUNDLE}" ] && sudo chmod 666 "${DB_BUNDLE}" "${CA_BUNDLE}" || true | |
| [ -f "${DB_BUNDLE}" ] && sudo chmod 666 "${DB_BUNDLE}" || true | |
| [ -f "${CA_BUNDLE}" ] && sudo chmod 666 "${CA_BUNDLE}" || true |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/infra/infra-dbdeployer-mysql95-binlog/bin/docker-mysql-post.bash` at
line 60, The chmod invocation assumes both DB_BUNDLE and CA_BUNDLE exist; update
the script around the line with [ -f "${DB_BUNDLE}" ] && sudo chmod 666
"${DB_BUNDLE}" "${CA_BUNDLE}" || true to guard each file individually or check
both exist first: ensure you test -f for "${DB_BUNDLE}" and -f for
"${CA_BUNDLE}" (or run separate guarded chmods) so chmod is only called on files
that actually exist; reference DB_BUNDLE and CA_BUNDLE and modify the
conditional logic accordingly.
Populates mysql90-g2 through mysql90-g5 with the same test assignments as mysql84-g2..5, matching the structure already applied to mysql95. Adds 147 group memberships, all targeting existing tests. mysql84-g2: 42 → mysql90-g2: 42 mysql84-g3: 40 → mysql90-g3: 40 mysql84-g4: 60 → mysql90-g4: 60 mysql84-g5: 5 → mysql90-g5: 5 mysql90-g1 intentionally left as the existing 16-test shared subset (still matches mysql91-g1 / mysql92-g1 / mysql93-g1). If you want g1 expanded to mysql84-g1 parity later (78 tests), it's a one-line follow-up. Fixes the runaway "TIMEOUT" seen in multi-group runs that included mysql90-g[2-5]: the tester would previously fall back to running all 325 tests when a group had no members (see separate commit that eliminates that fallback). check_groups.py still reports 385/385 registered, no orphans.
Previously, if TAP_GROUP was set but the group had no entries in
test/tap/groups/groups.json (typo, missing registration, etc.), the
tester logged a warning and silently fell back to running ALL 325 TAP
tests. In a multi-group parallel run this turns a misconfiguration into
a multi-hour hang that only surfaces when the per-group TIMEOUT fires.
We hit this in practice: mysql90-g[2-5] existed as launch targets in
the runner but hadn't been populated in groups.json yet. The tester
fell back to the full suite, and the groups TIMED OUT after chewing
through pgsql tests they had no business running.
Change behavior to log at CRITICAL and sys.exit(1) in two cases:
1. TAP_GROUP is set, groups.json is present, but the group has no
tests registered.
2. TAP_GROUP is set and groups.json is missing entirely.
The "no TAP_GROUP specified" path is unchanged — that's the legitimate
way to run the full suite directly (outside the group runner).
Error messages explicitly tell the operator what to do: either register
tests for the group, or unset TAP_GROUP to run the full suite
intentionally.
…T\G' MySQL 9.5.0 client (no longer?) accepts '\G' as a statement terminator when the statement is passed via '-e': $ mysql -e 'SHOW REPLICA STATUS\G' ERROR at line 1: Unknown command '\G'. '\G' still works interactively, and still works in -e on 8.4 and 9.0.1. This is a silent behavior change in the 9.5 client binary. (The 9.0.1 client in the same tarball tree handles '\G' fine.) docker-mysql-post.bash uses this to query replication status after container startup. Under 9.5, the mysql command exits non-zero, the captured output is empty, the subsequent grep in a pipeline returns 1, and set -e + pipefail kill docker-mysql-post.bash. That in turn kills docker-compose-init.bash which kills ensure-infras.bash. Net effect: every mysql95 / mysql95-binlog group fails before running a single test, logging just: Verifying MySQL on ...:3308... OK Checking replication on port 3307... (stops here) Fix: switch from '-e "SHOW REPLICA STATUS\G"' to '-E -e "SHOW REPLICA STATUS"'. '-E' (a.k.a. --vertical) has been supported by mysql(1) since 3.x, works identically on MariaDB 10, MySQL 5.7 / 8.4 / 9.0 / 9.5. The grep/awk that extracts Replica_IO_Running and Replica_SQL_Running keeps working unchanged since the vertical output format is the same. Applied to all 10 docker-mysql-post.bash files under test/infra/infra-dbdeployer-*. No change needed to the ci-infra Docker images — docker-mysql-post.bash runs on the host after the container starts.
Fixes #5627, #5628, #5630. The shared test helper test/tap/tap/utils.cpp:create_mysql_user() was hardcoding IDENTIFIED WITH 'mysql_native_password' in its CREATE USER template. MySQL 9.0 removed that plugin entirely (the .so in the tarball is a client-lib stub only; INSTALL PLUGIN fails with "Can't find symbol '_mysql_plugin_interface_version_'"), so CREATE USER IDENTIFIED WITH 'mysql_native_password' returns ER_PLUGIN_IS_NOT_LOADED on 9.x backends. Tests that use this helper as setup — they don't care which auth plugin the backend uses, they just need a working user — were failing before executing a single assertion. Affected tests (all in mysql90-g* / mysql95-g*): test_com_reset_connection_com_change_user-t (#5627) test_default_value_transaction_isolation_attr-t (#5628) test_server_sess_status-t (#5630) Fix: select the IDENTIFIED clause at runtime based on mysql_get_server_version(): - server < 9.0 → keep the explicit 'mysql_native_password' clause (preserves behavior on 5.7 / 8.4 for any callers that implicitly depend on a native-password backend user) - server >= 9.0 → use IDENTIFIED BY (server default plugin, which is caching_sha2_password on 9.x) Auth-sensitive tests that specifically exercise plugin-iteration (e.g. test_auth_methods-t, reg_test_4935-caching_sha2-t) do not use this helper — they use create_mysql_user_exp_creds() in utils_auth.h, which takes an explicit plugin argument. Those are handled in separate commits.
…st_auth_methods-t Fixes #5626. The test's fixture table (backend_users) has 18 users split 9/9 across mysql_native_password and caching_sha2_password. On MySQL 9.0+ the native-password plugin is unavailable, and the test bailed on creating the first native-password fixture (dualpass2). Following the existing version-gating pattern in the same test (which already branches on server_version < 80000 for MySQL 5.x and on is_mariadb for MariaDB), add a third branch: has_native_password = true if server_version >= 90000 && !is_mariadb: has_native_password = false Then thread has_native_password through: - the backend_users fixture list (filter out native entries before passing to config_mysql_backend_users) - def_auths (the "ProxySQL default authentication plugin" matrix) - req_auths (the "client-requested authentication plugin" matrix) plan() adjusts automatically because the plan count is computed from scs_stats/rnd_scs_stats which are derived from the actual created users and config_combs, not hardcoded. Coverage on 5.7 and 8.4 is unchanged: both plugins still exercised. On 9.x, only the caching_sha2_password half runs — which is the only half the backend can support anyway.
Fixes #5629. This regression test for issue #4935 ("proxysql ignores database in DSN at first login") uses a hardcoded plan(864) built around a 2×2 fixture table (2 mysql_native_password users + 2 caching_sha2_password users) crossed with 2 def_auths × 3 req_auths × 2×2×2 bool matrices. On MySQL 9.0+ the mysql_native_password plugin is unavailable and any CREATE USER IDENTIFIED WITH 'mysql_native_password' hits ER_PLUGIN_IS_NOT_LOADED, killing the test during fixture setup. Filtering the fixture matrix in-place to remove the native half would require re-deriving plan(N) from scratch — the current plan(864) encodes the expected-pass count of a non-trivial loop that has a per-iteration 'exp_first_login_failure()' skip. Getting that math right and keeping it right under future changes is fragile. Pragmatic fix: detect 9.x and skip the whole test with plan(0). The #4935 regression (database-in-DSN on first login for caching_sha2) is already fully exercised against the mysql57 and mysql84 infras in legacy-g* / mysql84-g*. Losing the 9.x-specific coverage for this one regression test is an acceptable trade-off — the ProxySQL code path under test is server-version-agnostic, so additional 9.x coverage adds little beyond what 8.4 already provides. Mirrors the skip pattern the test suite already uses for MySQL < 8.0.
…test_sqlite3_pass_exts-t Fixes #5631. The test has three logical phases: Phase 1 Admin SQLite3 extension validation for MYSQL_NATIVE_PASSWORD() and CACHING_SHA2_PASSWORD() — pure hash computation inside ProxySQL, does not touch the backend. Phase 2 MySQL/Admin hash compatibility — creates USER_GEN_COUNT (100) users on the backend, half with mysql_native_password and half with caching_sha2_password, then compares the backend's authentication_string with the hash that ProxySQL's Admin SQLite3 function produces. Phase 3 End-to-end connection test — creates RAND_USERS_GEN (100) users with the same 50/50 split and attempts to connect through ProxySQL. On MySQL 9.0+ the mysql_native_password plugin is not loadable, so the first CREATE USER IDENTIFIED WITH 'mysql_native_password' in Phase 2 fails with ER_PLUGIN_IS_NOT_LOADED and the test bails after only 10 assertions (all of Phase 1 passes — ProxySQL's internal hash extensions work fine on 9.x; this was a good green signal). Fix: - Add g_mysql_supports_native_password; set to false on server_version >= 9.0. - Adjust actual_test_count so plan() matches reality: if (has_native) { count += USER_GEN_COUNT + RAND_USERS_GEN; } else { count += USER_GEN_COUNT / 2 + RAND_USERS_GEN / 2; } - Wrap the Phase 2 native_password loop in 'if (has_native)'. - Phase 3 uses 'for (i = 0 .. RAND_USERS_GEN)' with 'i < 50 ? native : sha2'. Skip the native half by starting the loop at RAND_USERS_GEN/2 when has_native is false. Phase 1 coverage is fully preserved — the ProxySQL Admin SQLite3 hash functions (including MYSQL_NATIVE_PASSWORD()) still work on 9.x; only the backend-side CREATE USER path is skipped.
…_exts-t on 9.x Follow-up to cbbd10b (skip native_password backend fixtures on MySQL 9.x). The Phase-3 end-to-end loop runs RAND_USERS_GEN (100) iterations on 8.4 — 50 with mysql_native_password + 50 with caching_sha2_password — and each successful login creates one backend connection. On 9.x the native half is skipped, so only 50 actual connections are made. The post-loop assertion "Number of backend conns created should match conn attempts" was hardcoded to compare against RAND_USERS_GEN. When native was skipped, actual=50 but expected=100, producing: not ok 2113 - Number of backend conns created should match conn attempts exp:'100', act:'50' Fix: compute expected_conns based on g_mysql_supports_native_password (the same flag that gates the Phase-3 loop range) and use it both for the wait_for_cond() condition string and the assertion. Verified on a live mysql90 backend: test now reports ok 2113 - ... exp:'50', act:'50' and exits 0 (2113/2113 assertions pass in 3.4s).
Every TAP test in legacy-gN is now also a member of mysql84-gN,
mysql90-gN, and mysql95-gN (N=1..5). No tests removed from any group;
legacy-g[1-5] keeps its existing membership intact.
Rationale: the legacy group covers the MySQL 5.7 / MariaDB 10 / PgSQL /
ClickHouse matrix, but many of its TAP tests are not inherently tied to
MySQL 5.7 — they exercise ProxySQL behavior that should also hold
against modern MySQL backends (8.4, 9.0, 9.5). Running them against
those newer servers widens the matrix and catches 9.x-specific
regressions in tests that weren't previously in a 9.x group.
Mechanical merge via a walk over groups.json:
for each test:
for N in 1..5:
if 'legacy-gN' in memberships:
add 'mysql84-gN', 'mysql90-gN', 'mysql95-gN' if absent
224 new memberships added. Per-bucket union size (i.e. now a superset
of legacy-gN):
g1: legacy=87 mysql84=93 mysql90=87 mysql95=93
g2: legacy=43 mysql84=45 mysql90=45 mysql95=45
g3: legacy=40 mysql84=40 mysql90=40 mysql95=40
g4: legacy=94 mysql84=96 mysql90=96 mysql95=96
g5: legacy=5 mysql84=7 mysql90=7 mysql95=7
Verified as supersets (every test in legacy-gN is present in
mysql{84,90,95}-gN). check_groups.py reports 385/385 tests registered,
no orphans.
Expect new 9.x-specific failures to surface when the mysql{90,95}-g*
groups run these newly-inherited legacy tests — they're likely to hit
the same family of mysql_native_password / caching_sha2_password issues
we've already been working through in the sibling PR threads. Those
will be triaged as they appear.
Follow-up to 4534e5b (merge legacy-g[1-5] into mysql{84,90,95}-g[1-5]). The previous merge was over-inclusive: legacy-g* contains PostgreSQL tests (named 'pgsql-*' or 'pgsql_*' or '*_pgsql_*') that exercise ProxySQL's PostgreSQL front-end against the docker-pgsql16-single backend. Those tests don't care which MySQL version is also present, and the mysql{84,90,95} groups' infras.lst only lists infra-dbdeployer-mysqlXX — no PostgreSQL backend is brought up. So in myrun3 the merged pgsql tests failed (no backend) or hung until the per-group timeout (test_ffto_pgsql_concurrent-t). Removed 153 group memberships (pgsql-containing test names) from mysql{84,90,95}-g[1-5]. Safety check confirmed: no pgsql-containing test was in mysql*-g* before the merge, so this revert is scoped exactly to memberships the merge added. New sizes: legacy mysql84 mysql90 mysql95 g1 87 78 72 78 g2 43 45 45 45 g3 40 40 40 40 g4 94 61 61 61 g5 5 6 6 6 Net result vs pre-merge (pre-4534e5b4d): - mysql84-g1 back to 78 (same as pre-merge) - mysql90-g1 up from 16 to 72 (the non-pgsql legacy tests; +56) - mysql95-g1 back to 78 (same as pre-merge) - g2 / g3 / g5 unchanged from pre-merge for 84/95, mysql90-g* gets a few non-pgsql additions - g4 keeps the non-pgsql portion of the legacy merge (61 vs 60) Legacy-g[1-5] are untouched — pgsql tests remain where they belong. check_groups.py reports 385/385 registered, no orphans.
- validate_charset: compare server_version as a numeric major version instead of testing the first character, so MySQL 9.x and later are treated like 8.x for collations with id >= 255 - test_log_last_insert_id-t: re-enable PROXYSQL FLUSH LOGS; with buffered query logging, eventslog_flush_timeout=0 alone still races the periodic flush thread
|
1 participant
Summary
Two related test-infra changes that both fell out of the dbdeployer migration work:
Migrate
mysql84-grgroup to dbdeployer — replaces the older multi-container MySQL 8.4 Group Replication infra with a single dbdeployer-based container using--topology=group --single-primary. Matches the style already used bymysql57,mysql84,mariadb10, and the binlog variants.Cap
pgsql_servers.max_connectionsat 50 per hostgroup — the value was templated at 500 from the MySQL infras during the unify-PR-5433-5442 migration, but thedocker-pgsql16-singlePostgreSQL container only allows 120 connections (117 non-super). Under test load, PostgreSQL rejected Monitor connects withFATAL: remaining connection slots are reserved for roles with the SUPERUSER attribute, causingpgsql-monitor_ssl_connections_test-t(PHASE 1) andpgsql-servers_ssl_params-t(test 33) to fail intermittently. 50 per HG × 2 HGs = 100 pool connections, leaving headroom under PG's 120 for monitor + superuser slots.Changes
New infra (mysql84-gr):
test/infra/infra-dbdeployer-mysql84-gr/— entrypoint, Dockerfile, compose, ProxySQLinfra-config.sqlusingmysql_group_replication_hostgroupswithPREFIX=30(WHG=3000 / RHG=3001 / BHG=3002 / OHG=3003)Group wiring (mysql84-gr):
test/tap/groups/mysql84-gr/env.sh— setsDEFAULT_MYSQL_INFRAandREGULAR_INFRA_DATADIRtest/tap/groups/mysql84-gr/infras.lst— points at the new dbdeployer infratest/tap/groups/mysql84-gr/pre-proxysql.bash— rewritten to usedocker exec(the hook runs on the host; the previous version assumed ProxySQL was reachable at127.0.0.1:6032)PgSQL fix:
test/infra/docker-pgsql16-single/conf/proxysql/config.sql—max_connections500 → 50 on both pgsql_servers rowsTest plan
mysql84-gr-g1passing standalone (16/16 tests, ~6m)mysql84-gr-g1passing in 16-parallel multi-group run (myrun2, 6m5s)test_cluster_sync-twhich is a separate test-harness race being tracked)Summary by CodeRabbit