Thanks for your interest in improving store-valkey. 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-valkey 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. See the
README's Dependencies section for the exact layout;
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 Valkey — see the README's
Tests section. Locally, cargo test skips that coverage
cleanly if VALKEY_URL is unset; set it to point at a real Valkey to exercise it:
export VALKEY_URL=redis://localhost:6379/0
cargo build --release # cdylib
cargo test # unit tests + the e2e dlopen/live-Valkey 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-Valkey 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.
This repo is deliberately a thin adapter (src/lib.rs): it turns the engine's
JSON open config into a ValkeyStore and hands the trait object to
busbar-plugin-sdk,
which emits the C ABI symbols the loader resolves. All the Valkey schema,
serialization, and retry/TLS logic lives in the busbar-store-valkey library
crate this plugin wraps, in the busbarAI monorepo — most substantive changes
belong there, not here.
- 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.