feat: add VillageSQL flavor support#88
Conversation
VillageSQL is a MySQL drop-in replacement with extensions. Its tarballs are detected via the unique marker file share/villagesql_schema.sql and reuse MySQL's sandbox lifecycle unchanged. - Add VillageSQLFlavor constant and FnVillagesqlSchema marker - Add binary-detection rule before MySQL in FlavorCompositionList - Add VillageSQLCapabilities inheriting MySQLCapabilities.Features - Add tarball name detection regex and compatible flavors entry - Add CI workflow testing flavor detection with mock tarball - Add test cases for InstallDb, Initialize, MySQLX capabilities - Update CHANGELOG, README, and flavors documentation
Replace mock tarball approach with the official VillageSQL 0.0.3 release from GitHub. The workflow downloads the real tarball, verifies its SHA256 checksum, strips two broken symlinks (vsql-complex, vsql-tvector) that point outside the extraction directory, and tests that dbdeployer detects the flavor as "villagesql" via the share/villagesql_schema.sql marker. Sandbox deployment is not tested because VillageSQL uses its own version scheme (0.0.3) which does not map to MySQL's capability versions.
- Add detailed VillageSQL usage guide to docs/wiki/database-server-flavors.md covering download, --unpack-version requirement, single/replication deploy, and the broken symlink issue (villagesql/villagesql-server#237) - Add VillageSQL quick start section to README.md - Update CI to test real single + replication deployment using the official 0.0.3 tarball with --unpack-version=8.0.40 mapping - Update CHANGELOG with --unpack-version note
Three years of changelog entries were missing. Add detailed entries for v2.0.0 (PostgreSQL provider, ProxySQL, provider architecture), v2.1.0 (InnoDB Cluster, Group Replication, fan-in, all-masters, ProxySQL GR), v2.1.1 (macOS and install script fixes), v2.2.0 (MariaDB/Percona registry, ts tests), v2.2.1 (InnoDB Cluster fixes, ProxySQL fixes), and v2.2.2 (VillageSQL flavor support).
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 41 minutes and 20 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (10)
📝 WalkthroughWalkthroughThis pull request adds comprehensive VillageSQL flavor support to dbdeployer, including core flavor identification and capability registration, CI testing via a new GitHub Actions workflow, documentation updates across README and wiki pages, and extensive Claude Code agent planning documentation for future maintainer workflows. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![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 support for VillageSQL as a new database flavor, incorporating tarball detection, capability mapping, and usage documentation. Additionally, it adds a detailed implementation plan and design for a specialized Claude Code agent to assist with repository maintenance and verification. A review comment correctly identified a potential issue with shared map state in the capabilities definition, suggesting a copy to prevent side effects.
| var VillageSQLCapabilities = Capabilities{ | ||
| Flavor: VillageSQLFlavor, | ||
| Description: "VillageSQL server", | ||
| Features: MySQLCapabilities.Features, | ||
| } |
There was a problem hiding this comment.
VillageSQL is described as having extensions (custom types, VDFs). Assigning MySQLCapabilities.Features directly to VillageSQLCapabilities.Features results in both flavors sharing the same map instance in memory. Any future changes to VillageSQL's capabilities would inadvertently affect MySQL's capabilities as well. It is safer to create a copy of the map using addCapabilities with an empty list, similar to how PxcCapabilities is defined.
| var VillageSQLCapabilities = Capabilities{ | |
| Flavor: VillageSQLFlavor, | |
| Description: "VillageSQL server", | |
| Features: MySQLCapabilities.Features, | |
| } | |
| var VillageSQLCapabilities = Capabilities{ | |
| Flavor: VillageSQLFlavor, | |
| Description: "VillageSQL server", | |
| Features: addCapabilities(MySQLCapabilities.Features, FeatureList{}), | |
| } |
![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
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
common/checks.go (1)
879-892:⚠️ Potential issue | 🟠 MajorAdd VillageSQL-specific validation requiring
--unpack-version.VillageSQL tarballs are detected by flavor (common/checks.go lines 879–892), but the unpack flow accepts the embedded version (e.g.,
0.0.3) without validation. Since VillageSQL shares MySQL capability thresholds and requires a valid MySQL base version to function, unpacking without an explicit--unpack-versionproduces broken lifecycle scripts.Add a check in
ops/unpack.goafter version resolution (around lines 79–82) to reject VillageSQL tarballs unless--unpack-versionwas explicitly provided.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@common/checks.go` around lines 879 - 892, After resolving the package version in ops/unpack.go (immediately after the existing version-resolution logic around lines ~79–82), add a validation that if the detected flavor equals VillageSQLFlavor then an explicit unpack-version flag must have been provided; if not, return an error rejecting the unpack with a clear message instructing the user to supply --unpack-version. Use the VillageSQLFlavor symbol to detect the flavor and the existing variable that holds the user-supplied unpack version (e.g., unpackVersion or the flag variable used in unpack.go) to decide whether the flag was provided, and perform this check before proceeding with lifecycle script generation/unpacking.
🧹 Nitpick comments (4)
.github/workflows/villagesql_flavor_test.yml (4)
141-145: Combine both test invocations into onego testcall.Two separate
go test ./common/...calls re-resolve the module and recompile the test binary. Since both tests live in the same package, a single invocation with alternation is equivalent and faster.♻️ Proposed change
- - name: Run capability tests - run: go test ./common/... -v -run TestHasCapability -count=1 - - - name: Run copy capabilities tests - run: go test ./common/... -v -run TestCopyCapabilities -count=1 + - name: Run capability inheritance tests + run: go test ./common/... -v -run '^(TestHasCapability|TestCopyCapabilities)$' -count=1🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/villagesql_flavor_test.yml around lines 141 - 145, Replace the two separate workflows that run `go test ./common/...` for TestHasCapability and TestCopyCapabilities with a single `go test` invocation that runs both tests in one go; update the step that currently uses `-run TestHasCapability` and the step with `-run TestCopyCapabilities` to a single step using `go test ./common/... -v -run '^(TestHasCapability|TestCopyCapabilities)$' -count=1` so the package is compiled once and both tests execute.
42-42: Runner OS inconsistency between jobs.
villagesql-deploypinsubuntu-22.04(likely forlibaio1/libncurses5ABI compatibility with the MySQL 8.0.40 binaries), butvillagesql-capabilitiesusesubuntu-latest. Ifubuntu-latestrolls forward to 24.04+ and the Go toolchain or test semantics ever diverge from the deploy environment, pure-Go capability tests might still pass while deploy tests fail on a different path — masking issues during PR review. Consider pinning both to the same version for reproducibility.♻️ Proposed change
villagesql-capabilities: name: Capability Inheritance Tests - runs-on: ubuntu-latest + runs-on: ubuntu-22.04Also applies to: 133-133
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/villagesql_flavor_test.yml at line 42, The two workflow jobs use different runner images causing reproducibility drift; update the villagesql-capabilities job to use the same runner as villagesql-deploy by replacing its runs-on: ubuntu-latest with runs-on: ubuntu-22.04 (also ensure any other job that currently uses ubuntu-latest, e.g., the job at the other occurrence, is pinned to ubuntu-22.04) so both jobs (villagesql-deploy and villagesql-capabilities) run on the identical OS image for consistent test/deploy behavior.
108-123: Glob expansion in the deploy verification steps assumes exactly one sandbox.
~/sandboxes/msb_*/useand~/sandboxes/rsandbox_*/check_slavesrely on the shell matching a single path. If a prior step left stale sandboxes (for example, if thedelete allon line 115 partially failed), the glob expands to multiple arguments and the command either runs against the wrong sandbox or fails with a confusing error. Consider asserting exactly one match before invocation, or usingset -euo pipefail+ an explicit directory expansion.♻️ Example guard
- name: Test deploy single sandbox run: | + set -euo pipefail ./dbdeployer deploy single "$MYSQL_MAPPED_VERSION" --sandbox-binary="$SANDBOX_BINARY" - VERSION=$(~/sandboxes/msb_*/use -BN -e "SELECT VERSION();") + SB_DIRS=( ~/sandboxes/msb_* ) + [ "${`#SB_DIRS`[@]}" -eq 1 ] || { echo "FAIL: expected 1 msb sandbox, found ${`#SB_DIRS`[@]}"; exit 1; } + VERSION=$("${SB_DIRS[0]}/use" -BN -e "SELECT VERSION();") echo "Server version: $VERSION"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/villagesql_flavor_test.yml around lines 108 - 123, The workflow steps assume globs like ~/sandboxes/msb_*/use and ~/sandboxes/rsandbox_*/check_slaves expand to exactly one path, which breaks if stale sandboxes exist; update the Test deploy single sandbox and Test deploy replication sandbox runs to validate the glob expansion before invoking the command (for example, use a check that the glob expands to exactly one entry and fail early if not, or capture the expansion into a single variable and assert its count), then run the command against that validated path (references: the calls to "~/sandboxes/msb_*/use" and "~/sandboxes/rsandbox_*/check_slaves" / "~/sandboxes/rsandbox_*/test_replication" and the cleanup step "./dbdeployer delete all --skip-confirm").
64-73: Cache hit with a mismatched checksum will not self-heal.The download step guards with
if [ ! -f "$VILLAGESQL_TARBALL" ], so if a cached tarball exists but is corrupt, thesha256sum -cat line 72 will fail — which is correct — but the only remediation is manual cache invalidation (bumping-v1to-v2in the key at line 62). Consider falling back to a re-download when the checksum fails so transient cache corruption doesn't block CI indefinitely.♻️ Proposed change
- name: Download and verify VillageSQL tarball run: | mkdir -p /tmp/villagesql-tarball - if [ ! -f "/tmp/villagesql-tarball/$VILLAGESQL_TARBALL" ]; then - echo "Downloading VillageSQL $VILLAGESQL_VERSION..." - curl -L -f -o "/tmp/villagesql-tarball/$VILLAGESQL_TARBALL" "$VILLAGESQL_URL" - fi - echo "Verifying checksum..." - echo "$VILLAGESQL_SHA256 /tmp/villagesql-tarball/$VILLAGESQL_TARBALL" | sha256sum -c + TARBALL="/tmp/villagesql-tarball/$VILLAGESQL_TARBALL" + if [ -f "$TARBALL" ]; then + echo "$VILLAGESQL_SHA256 $TARBALL" | sha256sum -c --status || { + echo "Cached tarball corrupt; re-downloading..." + rm -f "$TARBALL" + } + fi + if [ ! -f "$TARBALL" ]; then + echo "Downloading VillageSQL $VILLAGESQL_VERSION..." + curl -L -f -o "$TARBALL" "$VILLAGESQL_URL" + fi + echo "Verifying checksum..." + echo "$VILLAGESQL_SHA256 $TARBALL" | sha256sum -c ls -lh "/tmp/villagesql-tarball/$VILLAGESQL_TARBALL"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/villagesql_flavor_test.yml around lines 64 - 73, The step that downloads and verifies the VillageSQL tarball currently skips download if $VILLAGESQL_TARBALL exists, so a corrupted cached file causes CI to fail permanently; modify the step to attempt a re-download on checksum failure: run the existing sha256sum -c check and if it fails delete /tmp/villagesql-tarball/$VILLAGESQL_TARBALL, re-download from $VILLAGESQL_URL into that path, and re-run sha256sum -c; if the second check still fails exit non‑zero so the workflow fails reliably. Include $VILLAGESQL_TARBALL, $VILLAGESQL_URL and $VILLAGESQL_SHA256 in the message/logging so it's clear what was retried.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/villagesql_flavor_test.yml:
- Line 41: The job name uses `${{ env.VILLAGESQL_VERSION }}` which is not
available in `jobs.<job_id>.name` so it will expand to empty; update the
workflow to either hardcode the version in the `name` line or move the value to
a supported context (e.g., define VILLAGESQL_VERSION under `vars:` or as a
workflow `input`) and reference it as `${{ vars.VILLAGESQL_VERSION }}` or `${{
inputs.VILLAGESQL_VERSION }}` in the `name` field; look for the `name: Deploy
(VillageSQL ${{ env.VILLAGESQL_VERSION }})` line and change the source of
VILLAGESQL_VERSION accordingly.
In `@docs/wiki/database-server-flavors.md`:
- Around line 64-70: The example shows running "dbdeployer deploy single 8.0.40"
but the displayed "SELECT VERSION()" output reports "8.4.8-..."; update the
example so the unpack/mapped version matches the server version (e.g., change
the deploy command to "dbdeployer deploy single 8.4.8") or, if 8.0.40 is
intentional, add a brief clarifying sentence after the example explaining why
the tree is labeled 8.0.40 while the server reports 8.4.8 (mentioning the
upstream build/relabeling reason and making clear that the SELECT VERSION()
output is expected).
- Around line 84-87: The fenced code block that lists the symlinks (the lines
starting with "mysql-test/suite/villagesql/examples/vsql-complex -> ..." and
"mysql-test/suite/villagesql/examples/vsql-tvector -> ...") needs a language
specifier to satisfy markdownlint; change the backtick fence from ``` to ```text
so the block begins with ```text and ends with ``` to mark it as plain text.
In `@README.md`:
- Line 91: The README currently claims VillageSQL supports Group Replication and
ProxySQL (the table row with "VillageSQL | ✓ | ✓ | ✓ | ✓ |"); update the README
to remove or downgrade the checkmarks for Group Replication and ProxySQL until
we add integration coverage, or alternatively add matching integration tests and
CI workflow entries that exercise Group Replication and ProxySQL wiring in the
PR test plan; locate the VillageSQL table row in README.md and either change the
relevant cells to a partial/indicator (e.g., "Partial" or "Planned") or ensure
the test workflow and integration tests (the PR test plan and workflow files
referenced in the repo) actually verify Group Replication and ProxySQL before
restoring the checkmarks.
- Around line 67-73: The README quick-start uses dbdeployer unpack directly on
villagesql-dev-server-0.0.3-dev-linux-x86_64.tar.gz which can fail due to
out-of-tree symlinks; update the instructions to either (a) use the cleaned
tarball path (the cleaned filename or URL for the symlink-free release) in the
curl/unpack example or (b) insert a pre-unpack symlink cleanup step (extract the
tar to a temp dir, remove or recreate offending symlinks, repack or point
dbdeployer at the cleaned directory) and/or add a link to the wiki workaround;
reference the tarball name villagesql-dev-server-0.0.3-dev-linux-x86_64.tar.gz
and the dbdeployer unpack command so readers can find and replace the failing
command.
---
Outside diff comments:
In `@common/checks.go`:
- Around line 879-892: After resolving the package version in ops/unpack.go
(immediately after the existing version-resolution logic around lines ~79–82),
add a validation that if the detected flavor equals VillageSQLFlavor then an
explicit unpack-version flag must have been provided; if not, return an error
rejecting the unpack with a clear message instructing the user to supply
--unpack-version. Use the VillageSQLFlavor symbol to detect the flavor and the
existing variable that holds the user-supplied unpack version (e.g.,
unpackVersion or the flag variable used in unpack.go) to decide whether the flag
was provided, and perform this check before proceeding with lifecycle script
generation/unpacking.
---
Nitpick comments:
In @.github/workflows/villagesql_flavor_test.yml:
- Around line 141-145: Replace the two separate workflows that run `go test
./common/...` for TestHasCapability and TestCopyCapabilities with a single `go
test` invocation that runs both tests in one go; update the step that currently
uses `-run TestHasCapability` and the step with `-run TestCopyCapabilities` to a
single step using `go test ./common/... -v -run
'^(TestHasCapability|TestCopyCapabilities)$' -count=1` so the package is
compiled once and both tests execute.
- Line 42: The two workflow jobs use different runner images causing
reproducibility drift; update the villagesql-capabilities job to use the same
runner as villagesql-deploy by replacing its runs-on: ubuntu-latest with
runs-on: ubuntu-22.04 (also ensure any other job that currently uses
ubuntu-latest, e.g., the job at the other occurrence, is pinned to ubuntu-22.04)
so both jobs (villagesql-deploy and villagesql-capabilities) run on the
identical OS image for consistent test/deploy behavior.
- Around line 108-123: The workflow steps assume globs like
~/sandboxes/msb_*/use and ~/sandboxes/rsandbox_*/check_slaves expand to exactly
one path, which breaks if stale sandboxes exist; update the Test deploy single
sandbox and Test deploy replication sandbox runs to validate the glob expansion
before invoking the command (for example, use a check that the glob expands to
exactly one entry and fail early if not, or capture the expansion into a single
variable and assert its count), then run the command against that validated path
(references: the calls to "~/sandboxes/msb_*/use" and
"~/sandboxes/rsandbox_*/check_slaves" /
"~/sandboxes/rsandbox_*/test_replication" and the cleanup step "./dbdeployer
delete all --skip-confirm").
- Around line 64-73: The step that downloads and verifies the VillageSQL tarball
currently skips download if $VILLAGESQL_TARBALL exists, so a corrupted cached
file causes CI to fail permanently; modify the step to attempt a re-download on
checksum failure: run the existing sha256sum -c check and if it fails delete
/tmp/villagesql-tarball/$VILLAGESQL_TARBALL, re-download from $VILLAGESQL_URL
into that path, and re-run sha256sum -c; if the second check still fails exit
non‑zero so the workflow fails reliably. Include $VILLAGESQL_TARBALL,
$VILLAGESQL_URL and $VILLAGESQL_SHA256 in the message/logging so it's clear what
was retried.
🪄 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: 8f0e5ecd-ed66-45d3-b6d7-19a1ee2642f6
📒 Files selected for processing (10)
.github/workflows/villagesql_flavor_test.ymlCHANGELOG.mdREADME.mdcommon/capabilities.gocommon/capabilities_test.gocommon/checks.godocs/superpowers/plans/2026-03-31-dbdeployer-specialized-agent-implementation.mddocs/superpowers/specs/2026-03-31-dbdeployer-specialized-agent-design.mddocs/wiki/database-server-flavors.mdglobals/globals.go
|
|
||
| jobs: | ||
| villagesql-deploy: | ||
| name: Deploy (VillageSQL ${{ env.VILLAGESQL_VERSION }}) |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
GitHub Actions context availability for jobs.<job_id>.name env
💡 Result:
No, the jobs.<job_id>.name (the display name of a specific job) is not directly available as an environment variable or in the job context. The job context provides information about the current running job only, with properties like job.status, job.check_run_id, but does not include a name property listing the display name (official docs list explicit properties without name). The jobs context is available only in reusable workflows and contains outputs and results of previous jobs (e.g., jobs.example_job.result), not names. However, within steps of the current job (after it starts running on the runner): - The job ID (YAML key, e.g., my-job) is available as the environment variable
Citations:
- 1: https://docs.github.com/en/actions/reference/accessing-contextual-information-about-workflow-runs
- 2: https://docs.github.com/en/actions/reference/contexts-reference
- 3: https://docs.github.com/en/actions/reference/workflows-and-actions/contexts
- 4: https://docs.github.com/en/actions/reference/workflows-and-actions/variables
- 5: https://stackoverflow.com/questions/61611978/get-current-job-name-in-github-actions-workflow
- 6: https://docs.github.com/en/actions/reference/variables-reference
🏁 Script executed:
cat -n .github/workflows/villagesql_flavor_test.yml | sed -n '35,50p'Repository: ProxySQL/dbdeployer
Length of output: 554
🏁 Script executed:
rg "VILLAGESQL_VERSION" .github/workflows/villagesql_flavor_test.yml -n -B 2 -A 2Repository: ProxySQL/dbdeployer
Length of output: 1599
env context is not available in jobs.<job_id>.name.
Per GitHub Actions context availability, jobs.<job_id>.name only supports github, needs, vars, inputs, matrix, and strategy — not env. The interpolation ${{ env.VILLAGESQL_VERSION }} will silently expand to an empty string, producing the job name Deploy (VillageSQL ).
Hardcode the version or move it to vars/inputs.
Proposed fix
villagesql-deploy:
- name: Deploy (VillageSQL ${{ env.VILLAGESQL_VERSION }})
+ name: Deploy (VillageSQL 0.0.3)
runs-on: ubuntu-22.04📝 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.
| name: Deploy (VillageSQL ${{ env.VILLAGESQL_VERSION }}) | |
| name: Deploy (VillageSQL 0.0.3) |
🧰 Tools
🪛 actionlint (1.7.12)
[error] 41-41: context "env" is not allowed here. available contexts are "github", "inputs", "matrix", "needs", "strategy", "vars". see https://docs.github.com/en/actions/learn-github-actions/contexts#context-availability for more details
(expression)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/villagesql_flavor_test.yml at line 41, The job name uses
`${{ env.VILLAGESQL_VERSION }}` which is not available in `jobs.<job_id>.name`
so it will expand to empty; update the workflow to either hardcode the version
in the `name` line or move the value to a supported context (e.g., define
VILLAGESQL_VERSION under `vars:` or as a workflow `input`) and reference it as
`${{ vars.VILLAGESQL_VERSION }}` or `${{ inputs.VILLAGESQL_VERSION }}` in the
`name` field; look for the `name: Deploy (VillageSQL ${{ env.VILLAGESQL_VERSION
}})` line and change the source of VILLAGESQL_VERSION accordingly.
| dbdeployer deploy single 8.0.40 | ||
| ~/sandboxes/msb_8_0_40/use -e "SELECT VERSION();" | ||
| # +-----------------------------------------+ | ||
| # | VERSION() | | ||
| # +-----------------------------------------+ | ||
| # | 8.4.8-villagesql-0.0.3-dev-78e24815 | | ||
| # +-----------------------------------------+ |
There was a problem hiding this comment.
Align the mapped version with the shown server version.
This example deploys the unpacked tree as 8.0.40, but the expected SELECT VERSION() output starts with 8.4.8. Either map/unpack as 8.4.8 or explain why 8.0.40 is intentionally used despite the server reporting an 8.4-based version.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/wiki/database-server-flavors.md` around lines 64 - 70, The example shows
running "dbdeployer deploy single 8.0.40" but the displayed "SELECT VERSION()"
output reports "8.4.8-..."; update the example so the unpack/mapped version
matches the server version (e.g., change the deploy command to "dbdeployer
deploy single 8.4.8") or, if 8.0.40 is intentional, add a brief clarifying
sentence after the example explaining why the tree is labeled 8.0.40 while the
server reports 8.4.8 (mentioning the upstream build/relabeling reason and making
clear that the SELECT VERSION() output is expected).
| ``` | ||
| mysql-test/suite/villagesql/examples/vsql-complex -> ../../../../villagesql/examples/vsql-complex/test | ||
| mysql-test/suite/villagesql/examples/vsql-tvector -> ../../../../villagesql/examples/vsql-tvector/test | ||
| ``` |
There was a problem hiding this comment.
Add a language to this fenced block.
markdownlint flags this fence; use text for the symlink listing.
Proposed fix
-```
+```text
mysql-test/suite/villagesql/examples/vsql-complex -> ../../../../villagesql/examples/vsql-complex/test
mysql-test/suite/villagesql/examples/vsql-tvector -> ../../../../villagesql/examples/vsql-tvector/test</details>
<!-- suggestion_start -->
<details>
<summary>📝 Committable suggestion</summary>
> ‼️ **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.
```suggestion
🧰 Tools
🪛 markdownlint-cli2 (0.22.0)
[warning] 84-84: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/wiki/database-server-flavors.md` around lines 84 - 87, The fenced code
block that lists the symlinks (the lines starting with
"mysql-test/suite/villagesql/examples/vsql-complex -> ..." and
"mysql-test/suite/villagesql/examples/vsql-tvector -> ...") needs a language
specifier to satisfy markdownlint; change the backtick fence from ``` to ```text
so the block begins with ```text and ends with ``` to mark it as plain text.
| ```bash | ||
| # Download from GitHub Releases | ||
| curl -L -o villagesql-dev-server-0.0.3-dev-linux-x86_64.tar.gz \ | ||
| https://github.com/villagesql/villagesql-server/releases/download/0.0.3/villagesql-dev-server-0.0.3-dev-linux-x86_64.tar.gz | ||
|
|
||
| # Unpack with MySQL 8.0 version mapping (required for capabilities) | ||
| dbdeployer unpack villagesql-dev-server-0.0.3-dev-linux-x86_64.tar.gz --unpack-version=8.0.40 |
There was a problem hiding this comment.
Make the quick-start use the cleaned tarball path.
The wiki notes VillageSQL 0.0.3 has out-of-tree symlinks that dbdeployer rejects, so this direct dbdeployer unpack example can fail for users following the README. Either add the symlink cleanup step here or link to the workaround before the unpack command.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@README.md` around lines 67 - 73, The README quick-start uses dbdeployer
unpack directly on villagesql-dev-server-0.0.3-dev-linux-x86_64.tar.gz which can
fail due to out-of-tree symlinks; update the instructions to either (a) use the
cleaned tarball path (the cleaned filename or URL for the symlink-free release)
in the curl/unpack example or (b) insert a pre-unpack symlink cleanup step
(extract the tar to a temp dir, remove or recreate offending symlinks, repack or
point dbdeployer at the cleaned directory) and/or add a link to the wiki
workaround; reference the tarball name
villagesql-dev-server-0.0.3-dev-linux-x86_64.tar.gz and the dbdeployer unpack
command so readers can find and replace the failing command.
The test was firing 254 full GET requests at MySQL's CDN in rapid succession. When the CDN rate-limits (HTTP 403), these cascaded into 77 failures, exceeding the max-3 threshold. Two fixes: - Use CheckRemoteUrl (HEAD-first) instead of checkRemoteUrl (full GET) to avoid downloading entire tarballs just to check URL reachability - Treat HTTP 403 as transient (CDN rate limit) rather than a hard failure, logging it separately - Add 50ms delay between requests to reduce rate limit triggering
Group Replication and ProxySQL wiring are not yet tested with VillageSQL. Mark them as unsupported until integration coverage is added.
Build and publish dbdeployer binaries automatically when a version tag (v*) is pushed. Produces linux/darwin x amd64/arm64 tarballs plus checksums.txt using the existing .goreleaser.yaml config.
The GitHub Actions workflow validator rejects ${{ env.* }} in
jobs.<job>.name — only github, inputs, needs, strategy, vars, and
matrix contexts are allowed there. This caused every push to master
to fail the villagesql_flavor_test workflow at dispatch (0s runs,
no jobs registered) since the PR #88 merge.
The version is a constant env var anyway; inline it.
1 participant
Summary
share/villagesql_schema.sqland reuse MySQL's sandbox lifecycle unchanged.Changes
VillageSQL flavor (
feat: add VillageSQL flavor support)globals/globals.go—FnVillagesqlSchemamarker constantcommon/capabilities.go—VillageSQLFlavorconstant, binary-detection rule (before MySQL inFlavorCompositionList),VillageSQLCapabilitiesinheritingMySQLCapabilities.Features,AllCapabilitiesentrycommon/checks.go— tarball name detection regex, compatible flavors entrycommon/capabilities_test.go— test cases for InstallDb, Initialize, MySQLX capability inheritanceCI (
ci: use real VillageSQL tarball...+docs+ci: add VillageSQL usage guide...).github/workflows/villagesql_flavor_test.yml— downloads the real VillageSQL 0.0.3 tarball from GitHub Releases, verifies SHA256 checksum, tests unpack with--unpack-version=8.0.40, deploys single and replication sandboxes, runs capability inheritance unit testsDocumentation
docs/wiki/database-server-flavors.md— full VillageSQL usage guide (download,--unpack-versionrequirement, single/replication deploy, symlink workaround)README.md— VillageSQL quick start section, VillageSQL row in Supported Databases tableCHANGELOG.md— entries for v2.0.0, v2.1.0, v2.1.1, v2.2.0, v2.2.1 (were missing)Important note
VillageSQL uses its own version scheme (e.g.
0.0.3) which does not map to MySQL's capability versions. Users must unpack with--unpack-versionmapped to the MySQL base version:Test plan
go build ./...compilesgo test ./common/...passes (new VillageSQL test cases + existing)Summary by CodeRabbit
New Features
Documentation