[manjari25]

Why?

The tango conflict analyzer talks to a Tango service, but running a real Tango needs a Bazel workspace, Bazelisk and a GitHub remote. That makes the demo and the integration tests heavy, and it ties them to a build system that has nothing to do with what they check. This adds a fake Tango server that speaks Tango's real gRPC protocol and gets its answers from a git repository, so the analyzer and tangoclient can run end to end in milliseconds.

Nothing uses it yet. The demo's ANALYZER=tango option will run the container and the integration and e2e tests will import the library, in later PRs of the stack. It answers only what the analyzer asks and computes no real build graph

What?

• tangofake: a Tango server that implements GetChangedTargets. A directory containing a TARGET file is a target (//dir), and the file lists its dependencies, one label per line. A change affects the nearest target above each file it touches at distance 0, and its dependents at distance 1, 2 and so on. Adding a TARGET file makes a target new, and deleting one makes it deleted.
• A change URI is resolved by the commit SHA at the end of it, so it works with both the git:// and github:// forms. The repository must hold that commit.
• service/tangofake: runs it as a service like the other ones in service/. server/ is the binary, which takes -repo, the clone to read, and -address, which defaults to a free port that it logs. It has a Dockerfile, a compose file that mounts the repository and listens on :8080 like the other services, a README, make build-tangofake-linux, and an entry in service/README.md.
• tangoclient: its package doc now says it is the only production package that imports Tango's generated types, and its visibility admits the fake's round-trip test.

Test Plan

• bazel test //service/tangofake/... runs the unit tests, including a round trip through tangoclient against a real git repository.
• To run it locally, use bazel run //service/tangofake/server -- -repo <path to a repo with TARGET files>, or make build-tangofake-linux and then the compose file in service/tangofake/server, with SQ_TANGOFAKE_REPO_DIR pointing at the repository.
• CI

Issue

[behinddwalls]

can we define it as a service like we do for runway or submitqueue? so that it can spinned in a container alongside the default set-up