Skip to content

All CI test cells depend on a personal fork's availability (tests/test_requirements.txt -> fcostaoliveira/RLTest) #530

Description

@fcostaoliveira

Summary

tests/test_requirements.txt pins the RLTest test harness to git+https://github.com/fcostaoliveira/RLTest.git@<sha> -- a personal account's fork, not something the redis org controls. This predates PR #526; that PR only tightened the pin from a mutable branch name to an immutable commit SHA, which closes the force-push/rename-in-place risk but not an availability one.

Why this is more than one test cell's problem

Every CI job that runs Python tests -- across ci.yml, asan.yml, tsan.yml, ubsan.yml, every matrix cell, standalone and cluster alike -- has its own "Install Python dependencies" step running pip install -r ./tests/test_requirements.txt (confirmed: this step lives inside the per-matrix-cell job, not a shared setup job). If fcostaoliveira/RLTest is ever deleted, renamed, or made private, every one of those pip install steps fails immediately, before any test even runs -- not just the one OSS-CLUSTER + replicas: client-no-touch cell that actually depends on the fork's behavior (cluster-aware --use-slaves replicas).

Discovered while answering a review question on PR #526 about whether a new hard-failing test (vs. the pre-existing skip-tolerant ones) changes this risk. It doesn't: pip install failing happens before test collection, so whether a downstream test would have skipped or hard-failed on missing replicas is moot -- the whole job dies at dependency-install time either way.

Suggested fix

Mirror the fork under an org-controlled location (a redis-org repo, or vendoring the specific patch as a local diff applied in CI) rather than depending on an individual's GitHub account staying available indefinitely. Revert to git+https://github.com/RedisLabsModules/RLTest.git@master entirely once upstream RedisLabsModules/RLTest#253 merges (already noted as TEMPORARY in tests/test_requirements.txt).

Discovered while working on

PR #526 review, round 26.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions