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 cd ~/vienalatina
git remote add gitea https://git.vienalatina.com/pablo/vienalatina.git git remote add gitea https://git.vienalatina.com/pablo/vienalatina.git
git push gitea main 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**): 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 reports success and the server behaves exactly as it did before, which is the
most expensive kind of nothing. 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 ```sh
cd ~/vienalatina 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 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 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 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 lives only on the server — but it does compare it against `.env.example` and