You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit bdb5d8a
Browse filesBrowse the repository at this point in the historyBrowse files
# Where PROVIDER=git keeps the bare repository it lands into. Outside the
70
76
# repository, so a demo leaves nothing in a checkout, and bind-mounted rather
@@ -165,7 +171,7 @@ build: ## Build all services and examples
165
171
# Build Linux binaries required for the local docker-compose flows (local-*).
166
172
# Bazel-run integration/e2e tests do NOT need these: they build the service
167
173
# binaries hermetically as data dependencies.
168
-
build-all-linux: build-submitqueue-gateway-linux build-submitqueue-orchestrator-linux build-stovepipe-linux build-runway-linux ## Build all Linux binaries for Docker
174
+
build-all-linux: build-submitqueue-gateway-linux build-submitqueue-orchestrator-linux build-stovepipe-linux build-runway-linux build-tangofake-linux ## Build all Linux binaries for Docker
169
175
@echo "All Linux binaries ready for Docker"
170
176
171
177
build-runway-linux: ## Build Runway Linux binary for Docker
@@ -389,7 +395,7 @@ local-submitqueue-clean: ## Stop the stack and remove its volumes, images, and P
389
395
@echo "Cleaning all services and data..."
390
396
@# The overlay is named so that volumes it declares — Runway's checkouts —
391
397
@# are removed too, rather than surviving as an orphan.
392
-
@$(COMPOSE) -f $(COMPOSE_FILE) -f $(PROVIDER_COMPOSE_FILE) -f $(WEB_COMPOSE_FILE) -p $(SUBMITQUEUE_LOCAL_PROJECT) down -v --rmi local
398
+
@$(COMPOSE) -f $(COMPOSE_FILE) -f $(PROVIDER_COMPOSE_FILE) -f $(WEB_COMPOSE_FILE) -p $(SUBMITQUEUE_LOCAL_PROJECT) down --remove-orphans -v --rmi local
393
399
@rm -rf "$(SQ_GIT_SANDBOX_DIR)"
394
400
@echo "All services, volumes, images, and $(SQ_GIT_SANDBOX_DIR) removed."
395
401
@@ -534,14 +540,18 @@ local-submitqueue-restart: build-all-linux ## Restart all services (rebuild and
Copy file name to clipboardExpand all lines: doc/howto/QUICKSTART.md
+24Lines changed: 24 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -259,6 +259,30 @@ Three changes, one more ref update than before.
259
259
260
260
The sandbox survives `make local-submitqueue-stop`, so what landed is still there to look at. `make local-submitqueue-clean` removes it.
261
261
262
+
## Decide conflicts with Tango
263
+
264
+
`PROVIDER=git` decides that two changes conflict by comparing the directories they touch. An analyzer built on a build graph can see more: a change to a library conflicts with a change to anything built on it, though their paths never overlap. `ANALYZER=tango` swaps the analyzer for one that asks a Tango server which build targets each batch affects, and runs a fake Tango server beside the stack so it needs no build system.
265
+
266
+
```bash
267
+
make local-submitqueue-stop
268
+
make local-submitqueue-start PROVIDER=git ANALYZER=tango
269
+
make demo-requests
270
+
make local-submitqueue-stop PROVIDER=git ANALYZER=tango
271
+
```
272
+
273
+
Starting with `ANALYZER=tango` also commits a `TARGET` file into each `demo/NN` folder of the sandbox, on top of whatever is already there. `demo/00` and `demo/01` are libraries, and every other folder depends on one of them: even folders on `demo/00`, odd folders on `demo/01`. Pass the same `ANALYZER` when stopping, so the fake server is stopped with the rest. Only the folders `demo/00` to `demo/09` have targets, so `make demo-requests` refuses a `FOLDERS` above 10 against a sandbox seeded this way, because changes in a folder without a target would never conflict.
274
+
275
+
Look at what the analyzer recorded, the same way as in the speculation section above:
276
+
277
+
```bash
278
+
docker exec submitqueue-mysql-app-1 mysql -uroot -proot submitqueue \
279
+
-N -e "select batch_id, dependents from batch_dependent where dependents != '[]'"
280
+
docker exec submitqueue-mysql-app-1 mysql -uroot -proot submitqueue \
281
+
-N -e "select count(*) from target_signature"
282
+
```
283
+
284
+
The second count has a row for every batch analyzed, which shows the orchestrator really asked the fake server. Dependencies between batches can now join different folders, where under path overlap they only join batches sharing one.
285
+
262
286
## Land against GitHub
263
287
264
288
The last rung is the only one that needs credentials, and the only one where a change is a pull request that a person can review.
Copy file name to clipboardExpand all lines: service/submitqueue/demo/provider/README.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,6 +19,8 @@ Pick one with `make local-submitqueue-start PROVIDER=<name>`, which bind-mounts
19
19
20
20
The three are a ladder, and the rung is the only thing that changes: the same commands land against all of them. `git/` is worth reading first of the two real ones. It is proof that neither half needs a provider — change metadata comes from reading the repository and the merge is the same Runway code path, both against a bare repository addressed by path, with no credential and no API — and it is what the hermetic git E2E (`make e2e-git-test`) runs against.
21
21
22
+
The conflict analyzer is a separate choice from the provider. `make local-submitqueue-start PROVIDER=git ANALYZER=tango` keeps everything about `git/` and swaps `demo-queue`'s analyzer for Tango, answered by the fake server in [`service/tangofake`](../../../tangofake). It reads [`git/profiles.tango.yaml`](git/profiles.tango.yaml) instead of `profiles.yaml`, and the sandbox gains a `TARGET` file per `demo/NN` folder. Only `PROVIDER=git` supports it, because the fake reads targets from that provider's repository.
23
+
22
24
Note that the orchestrator and Runway each keep their **own** copy of a queue's repository and configure their own remote for it: the change provider's copy is in `profiles.yaml`, the merger's checkout in `merge.yaml`, and they are independent even when they name the same remote. That is the same shape a deployment has when both point at a remote host.
0 commit comments