doxa-life/doxa-maps
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

README: land on the pilot through a throwaway merge, so the PR branch stays one feature on the landing branch

Browse source 
Step 5 merged the pilot INTO the PR branch, which made the PR branch carry everyone's unpublished
work. It now merges the PR branch into a detached copy of the pilot inside the lock, checks, pushes
that merge, and switches back; a conflict is aborted and fixed on the PR branch. Step 4 says the
per-agent preview servers run on your own machine, and the cloud paragraph says to set the container's
BRANCH to development for the pilot server (its default is main).
This commit is contained in:
Doxa Maps 2026-10-02 05:36:24 +00:00
parent dceb824e3f
commit bf140e38c9
1 changed files with 14 additions and 8 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

22
README.md
View file

@ -727,19 +727,24 @@ gate-keeper that reads each change before it lands, are jobs your harness gives
git worktree add -b upg100/work ../dx-maps-upg100 origin/main
cd ../dx-maps-regions && bun install --frozen-lockfile
```
4. **One preview server per agent, each on its own port:**
4. **One preview server per agent on your own machine, each on its own port** (in the cloud, the one
pilot server below takes this role):
```bash
bun x vite --port 5301 --strictPort # the next agent uses 5302, and so on
```
5. **Land on the pilot one at a time, through a lock.** Inside the lock, merge the pilot branch into
your PR branch, run the checks, and push only if nothing fails (`gates:pre` exits non-zero when a
check fails, so the push never runs then):
5. **Land on the pilot one at a time, through a lock.** Inside the lock, merge your PR branch into a
throwaway copy of the pilot branch, run the checks, and push that merge only if nothing fails
(`gates:pre` exits non-zero when a check fails, so the push never runs then). Your PR branch itself
stays one feature on the landing branch; only the pilot gets the merge:
```bash
flock /tmp/dx-maps-development.lock sh -c '
git fetch origin && git merge --no-edit origin/development &&
bun run gates:pre && git push origin HEAD:development'
git fetch origin && git switch --detach origin/development &&
git merge --no-edit regions/work &&
bun run gates:pre && git push origin HEAD:development
git switch regions/work'
```
`flock` guards one machine. Agents on several machines need a shared lock, such as one your
If the merge stops on a conflict, run `git merge --abort`, fix the clash on your PR branch and land
again. `flock` guards one machine. Agents on several machines need a shared lock, such as one your
harness provides.
6. **One agent owns the full build**; the others build only their own plugin:
```bash
@ -762,7 +767,8 @@ gate-keeper that reads each change before it lands, are jobs your harness gives
Keep the repository on a forge you host yourself: a swarm pushes often, and on a public host one wrong
push publishes work you did not mean to share. Give each app two servers: a **pilot server** that
follows the pilot branch with hot reload, and a **landing server** that rebuilds from the landing
branch. The cloud container in `deployment/cloud/` runs both today. One pilot server per app, rather
branch. The cloud container in `deployment/cloud/` runs both today (set its `BRANCH` to `development`
for the pilot server; the default is `main`). One pilot server per app, rather
than one per pull request, keeps the memory the same however many pull requests are open. Each
developer can still build on their own machine with the Plugin Studio and push their branch.