Thanks for your interest in improving store-mysql. This document covers how
to build, test, and submit changes.
- Be respectful and constructive in all project spaces (see CODE_OF_CONDUCT.md).
- By contributing, you agree your contributions are licensed under the project's Apache-2.0 license.
- Security issues go through SECURITY.md, not public issues.
store-mysql is a Rust cdylib plugin. You need a recent stable toolchain
(rustup recommended), and — until busbarAI
ships publicly — a sibling checkout of it at ../busbarAI, since this crate's
Cargo.toml points at busbar's crates as local path dependencies. CI checks out
GetBusbar/busbar at the branch named in the reusable plugin-ci.yml workflow
reference in ci.yml.
The meaningful test coverage here needs a live MySQL — see the README's
Testing section. Locally, cargo test skips that coverage
cleanly if BUSBAR_TEST_MYSQL_URL is unset; set it to point at a real MySQL 8
database to exercise it:
export BUSBAR_TEST_MYSQL_URL=mysql://busbar:busbar@127.0.0.1:3306/busbar_test
cargo build --release # cdylib
cargo test # unit tests + the e2e dlopen/live-MySQL test
cargo clippy --all-targets -- -D warnings # lints must be clean
cargo fmt --all -- --check # format before committingcargo fmt --all— code must be rustfmt-clean.cargo clippy --all-targets -- -D warnings— no warnings.cargo build && cargo test— green, including the live-MySQL end-to-end test intests/e2e.rs(it hard-fails underCI=1rather than silently skipping — never let that coverage quietly vanish).- Add or update tests for any behavior change.
- Update documentation (
README.md, doc comments) when you change behavior or config.
The plugin crate (store-mysql-plugin/) is deliberately a thin adapter: it
turns the engine's JSON open config into a MysqlStore and hands the trait
object to
busbar-plugin-sdk,
which emits the C ABI symbols the loader resolves. All the SQL and schema logic
lives in the busbar-store-mysql library crate in the store-mysql/ directory
of THIS repository, so most substantive changes belong there.
- Keep commits focused; squash noisy WIP commits before opening the PR.
- Write a clear PR description: what changed, why, and how it was verified.
- Reference any related issue.
- Stage files by name; avoid sweeping
git add -Athat pulls in unrelated changes.
Open a discussion or issue. We're happy to help you get oriented.