Hi, I think we can do:
1. make the test reports an honest GTEST_SKIP() 2. Add a new CI job with real redis server installed Thanks, Weibing Wang On Fri, May 29, 2026 at 12:28 PM Varun Raj <[email protected]> wrote: > > Hi all, > > The Redis backend tests are effectively not exercised in CI, yet stay green. > > Problem: test/brpc_redis_unittest.cpp needs a real external > redis-server. When it's > absent each redis test just returns -- which gtest counts as PASS, not > SKIP. CI never > installs redis, so in the latest master run (commit 0835315): > > Skipped due to absence of redis-server x7 > [ PASSED ] 14 tests. > > So 7 of 14 RedisTest cases are false-green (Memcache shows the same > pattern). Job log: > https://github.com/apache/brpc/actions/runs/26615492838/job/78430157550 > (Attached: redis_ci_skip_proof.png -- CI log excerpt, red = skipped, > green = reported PASSED.) > > Proposal: > 1. Add a skip-vs-fail flag BRPC_TEST_REDIS_REQUIRED (default false): > when off and redis > is absent the test reports an honest GTEST_SKIP() (not a fake PASS) > -- the normal > local unit-test behavior; CI sets it true so missing redis hard-fails. > Tests > discover/launch redis, never install it. The same flag pattern > (BRPC_TEST_<BACKEND>_REQUIRED) is reusable for MySQL and other backends. > 2. Install a pinned redis in the CI unittest job so these run as real > integration tests > ("latest" is non-deterministic -- the auth test already had to be > adapted for redis 6.0). > 3. (Future work, optional) a docker-compose integration harness (deps > + pinned redis) so > contributors can reproduce these integration tests locally without > a system redis. > > Questions: Is there appetite to install backend servers in CI (redis > first) and gate > these integration tests on a flag (parts 1-2)? And later, interest in > the optional Docker > harness (part 3) for reproducible local runs? (These are integration > tests, kept distinct > from the unit tests.) > > If there's interest I'll send the Redis PR, then follow the same > approach for the MySQL > backend (generalizes to Memcache and others). > > Thanks, > Varun > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
