pablo/vienalatina
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Say which remote to pull from, because git will not

Browse Source 
The server's main tracks gitea/main while new work lands on a branch on
GitHub, so a bare `git pull` asks Gitea, finds it level, and answers
"Already up to date." That sentence is true about the wrong remote and
reads exactly like there is nothing to fetch — which is how the last
deploy stalled on a script that had never arrived.

Step 8 now names a `github` remote beside `gitea`, and the update recipe
in 11.3 pulls from it by name with --no-edit, pushes to gitea, then
rebuilds. 11.3 previously said plain `git pull`, as though the server
tracked GitHub.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NizVpJ2dwzCbjCrTLCjeHn
This commit is contained in:
Claude 2026-09-25 18:54:00 +00:00
parent ed6b568d60
commit bf7ff3025a
No known key found for this signature in database
1 changed files with 28 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
docs/server-setup.md
View File

@ -193,9 +193,16 @@ your laptop):
cd ~/vienalatina
git remote add gitea https://git.vienalatina.com/pablo/vienalatina.git
git push gitea main
# Name the GitHub remote too, while you are here. The clone in step 5 called it
# `origin`, but `main` came to track `gitea/main` — so a bare `git pull` asks
# Gitea, and new work arrives on GitHub. Having both named saves you from typing
# the URL every time you deploy.
git remote add github https://github.com/pablovolenski/vienalatina.git
git remote -v
```
(It will ask for your Gitea username/password.)
(Gitea will ask for your Gitea username/password.)
In Woodpecker (**https://ci.vienalatina.com**):
@ -381,14 +388,32 @@ nothing that is running, and neither does `docker compose up -d
reports success and the server behaves exactly as it did before, which is the
most expensive kind of nothing.
An update is a rebuild:
**And `git pull` on its own will not fetch it.** This is worth knowing before
it costs you an afternoon: `main` on the server tracks `gitea/main`, while new
work is pushed to a branch on **GitHub**. So a bare `git pull` asks Gitea,
finds Gitea level with your local `main`, and answers *"Already up to date."* —
which is true about the wrong remote, and reads exactly like there is nothing
to do.
An update is a named pull, a push to Gitea so the build pipeline sees it, and a
rebuild:
```sh
cd ~/vienalatina
git pull
git pull --no-edit github <the-branch-name> # e.g. claude/relaxed-faraday-h4zd09
git push gitea main
sudo bash scripts/deploy-board.sh
```
`--no-edit` accepts the default merge message. Without it git opens an editor,
which is a strange place to find yourself mid-deploy.
If `github` is not a remote yet, add it once — see the end of step 8:
```sh
git remote add github https://github.com/pablovolenski/vienalatina.git
```
That rebuilds the image, copies the compose file across, restarts, and prints
the log. It never touches `/srv/board/.env` — that file holds the secrets and
lives only on the server — but it does compare it against `.env.example` and