Druhý krok po #16, rovnou celý. Dvojkolejnost dávala smysl pro projekt
s neznámými uživateli; tady běží jedna instance a ta je přemigrovaná.
Pryč je:
- deploy/pve-kostky.sh (přesměrování na nový skript)
- stěhování ze starého jména v instalátoru včetně bloku STARY_*
- záložní jméno přílohy kostky-* v instalátoru
- věšení příloh pod dvěma jmény v obou workflow
- záloha na ~/.local/share/kostky/dice.db ve storage.py
- odstavce o přechodu v README
Jediné, co ve zdrojácích zůstalo, je docstring "Pravidla hry v kostky"
v core.py — to je česky pojmenovaná hra, ne identifikátor.
POZOR na pořadí: instalátor teď hledá jen dice-counter-*, a poslední
vydání (v1.2.1) má na releasu pouze kostky-*. Do otagování v1.2.2 tedy
`update` ani čerstvá instalace nemají co stáhnout. Merge a tag patří
k sobě.
Ověřeno v debianím kontejneru: čistá instalace, druhé spuštění za sebou,
a vydání bez nových jmen spadne se srozumitelnou hláškou místo toho, aby
sáhlo po starém. Binárka postavená lokálně zakládá databázi v
…/dice-counter/ a starou vedle sebe ignoruje. 118 testů.
Closes#19
Projekt se jmenuje dice-counter, ale skoro všude vystupoval jako kostky.
Tohle je první ze dvou kroků podle #16: nová jména se zavádějí vedle
starých, aby běžící instalace nic nerozbilo.
Nově:
binárka a spec dice-counter.spec, dist/dice-counter
přílohy releasu dice-counter-linux-x86_64 a spol.
služba v LXC dice-counter.service
cesty v LXC /opt/dice-counter, /var/lib/dice-counter
uživatel dice-counter
hostname LXC dice-counter
instalátor deploy/pve-dice-counter.sh
datový adresář ~/.local/share/dice-counter a obdoby
co appka hlásí "dice-counter <verze>" v banneru i v patičce
Stará jména zatím fungují dál:
- Přílohy se na release věší pod oběma jmény.
- Instalátor umí stáhnout i kostky-*, takže starší vydání jdou
nainstalovat pořád.
- deploy/pve-kostky.sh zůstává jako přesměrování — příkaz `update`
v už založených kontejnerech chodí pro instalátor právě tam.
- Kontejnery z dřívějška se při aktualizaci přestěhují samy: služba
se přejmenuje a databáze se přesune do /var/lib/dice-counter, takže
o historii her nikdo nepřijde.
- Binárka sáhne po ~/.local/share/kostky/dice.db, dokud nová databáze
neexistuje.
Při zkoušení přechodu vyplavala chyba, která tu byla už předtím: příkaz
`update` si nový instalátor uloží do $HOME_DIR/install.sh a odtud ho
pustí, takže `install -m 755 "$0" "$HOME_DIR/install.sh"` kopírovalo
soubor sám na sebe. install to odmítne, se `set -e` spadl celý update.
Ošetřeno testem `-ef`.
Ověřeno v debianím kontejneru: přechod ze staré instalace (včetně běhu
instalátoru z adresáře, který se během něj maže), čistá instalace, běh
proti releasu, kde je jen stará příloha, a druhé spuštění za sebou.
Refs #16
Domácí runner běží v LXC. binfmt_misc je vlastnost jádra hostitele a do toho
se kvůli počitadlu kostek vrtat nebude — je produkční. tonistiigi/binfmt sice
hlásil úspěch, ale na hostiteli po něm nezůstala žádná registrace, takže
buildkit arm64 mezi platformami nikdy neuvidí.
Stejná dělba jako u binárek: doma se hlídá, na GitHubu se vydává. Zdejší
workflow staví nativní amd64 obyčejným `docker build` a zkouší ho spustit nad
každým pull requestem; žádný buildx, žádná emulace, nic, co by na runneru
mohlo chybět. Publikaci multiarch image převzalo .github/workflows/image.yml,
kde jsou běhouni plnohodnotné virtuály a emulace funguje bez zásahu.
Publikovat jde nově jen z tagu. Ruční spuštění nad větví by udělalo `:latest`
ukazující na rozdělanou práci.
Compose soubor měl v sobě build: context: .., takže si image stavěl z
lokálních zdrojáků a bez naklonovaného repozitáře byl k ničemu. Proti LXC
cestě, kde se stahuje hotová binárka, to byla nesrovnalost.
Nové workflow staví image na domácím runneru a při vydání ho pošle do
registru Gitey, pro amd64 i arm64. Compose se tím smrskl na jeden soubor,
který si člověk stáhne a rovnou spustí.
Automatický token Actions na balíčky nestačí — Gitea to zatím neumí a sama
v dokumentaci odkazuje na osobní token. Je v secrets pod PACKAGE_TOKEN;
jméno nesmí začínat na GITEA_, ten prefix si Gitea vyhrazuje.
Nad pull requesty se image staví a zkouší, ale nepublikuje. Dockerfile do
teď v CI žádné pokrytí neměl a rozbil by se až při releasu.
Image se jmenuje podle repozitáře, dice-counter. Zbytek projektu pořád mluví
o kostkách; sjednocení je na samostatné issue, protože se dotkne vydaných
binárek i běžících instalací.
Dvě věci, které se u community-scripts čekají a chyběly.
V kontejneru je nově /usr/bin/update, takže aktualizace je jedno slovo. Sám
si přitom obnoví i instalátor z main, aby nejel napořád na té verzi skriptu,
se kterou se instalovalo. Cesta z uzlu (MODE=update) zůstává.
A konzole: kontejner schválně nemá root heslo, jenže pak se do konzole ve
webu Proxmoxu nedalo dostat — uživatel žádné přihlašovací údaje nezná a ani
nemá odkud. Autologin přes container-getty@1 to řeší přesně tak, jak to
dělají community-scripts. Nová práva to nikomu nedává, kdo má web Proxmoxu,
má root na uzlu tak jako tak. Vypíná se AUTOLOGIN=0.
Debian 13 veze systemd 257 a ten v neprivilegovaném LXC bez nestingu
nedostane, co potřebuje — Proxmox na to při startu sám upozorňuje hláškou
"Systemd 257 detected. You may need to enable nesting."
Appka i tak nastartovala, ale spoléhat se na to nemá cenu. Stejnou výchozí
hodnotu mají i community-scripts a sami varují, že moderní distribuce se
systemd nesting potřebují.
Instalace teď vypadá tak, jak se u community-scripts čeká:
bash -c "$(curl -fsSL .../deploy/pve-kostky.sh)"
Dva soubory to neuměly. Přes rouru z curlu není na disku hostitele žádný
soubor, který by šel poslat do kontejneru, takže se instalátor přesunul
dovnitř skriptu jako text v heredocu. Duplicita tím nevzniká — vypsat se dá
zpátky přes `bash pve-kostky.sh instalator`, když ho chce někdo pustit
v kontejneru, který si založil sám.
Argumenty se rourou předávají mizerně, tak jde všechno i proměnnou:
CTID=123 MODE=update. Ze staženého souboru funguje i pozičně.
Ke stejné příležitosti: úložiště se přestalo hádat. local-lvm na ZFS
instalacích neexistuje a pct create by spadlo až po půlce práce; teď se
vybere první aktivní, a když se nějaké vnutí, ověří se, že vůbec existuje.
Aby se to dalo nechat běžet pořád, ne jen spouštět večer na notebooku.
pve-kostky.sh se pouští na uzlu Proxmoxu, založí kontejner a předá řízení
lxc-install.sh, který uvnitř stáhne vydanou binárku, ověří kontrolní součet
a zapíše službu. Ty dva jsou oddělené schválně: instalátor o Proxmoxu nic
neví, takže se dá pustit i v kontejneru, který sis založil sám. Podoba je
odkoukaná od community-scripts.org, ale nic z jejich frameworku se nestahuje
— jejich build.func si instalační skript hledá natvrdo ve vlastním
repozitáři, takže mimo něj nefunguje.
Docker se staví ze zdrojáků, ne z binárky: image pak jde sestavit pro obě
architektury a nezávisí na tom, jestli release proběhl. Zamčené závislosti
z minula dělají sestavení opakovatelné.
Compose používá síť hostitele, a to je podstatné. V bridge režimu vidí
kontejner uvnitř adresu 172.17.0.2, tabule ji poctivě nabídne a udělá na ni
QR kód — jenže z telefonu je nedosažitelná. Ověřeno, ne odhadnuto; kdo bridge
potřebuje, musí nastavit DICE_HOST.
Aplikace sama nepotřebovala změnit nic. DICE_DB, DICE_PORT a DICE_HOST
pokrývají obojí a v LXC má kontejner vlastní adresu v LAN, takže hledání
adres i QR kód fungují beze změny.
Dokud se hrálo ze zdrojáků, ležel dice.db v pracovním adresáři a záloha byla
otázka zkopírování. Z binárky se schovává do systémového datového adresáře,
který na Windows běžný člověk nenajde — takže se teď dá stáhnout přes
prohlížeč.
VACUUM INTO udělá konzistentní kopii i uprostřed zápisu, na rozdíl od
prostého přečtení souboru. Kopie se přečte do paměti a hned zahodí, ať
nezůstane ležet v dočasném adresáři, když si ji někdo nestáhne celou.
GitHub dává veřejným repozitářům běhouny ubuntu-24.04-arm zadarmo, takže je
to jeden řádek do matice. Hodí se pro Raspberry Pi nebo jinou malou pořád
zapnutou krabičku, což je rozumnější místo, kde tohle nechat běžet, než
notebook, který se každý večer zapíná.
x86-64 zůstává doma. Tam jde stavět proti staré glibc a když GitHub vypadne,
release má pořád tu platformu, na které to reálně poběží. ARM je výjimka
prostě proto, že doma na něm není na čem postavit.
Flask pod pěkně naformátovanou úvodní hlášku vysypal červené varování, že
tohle není produkční server. Waitress je čistě pythonní, takže ho PyInstaller
zabalí bez řečí, a osm vláken pobere telefony u stolu i tabuli, která se
doptává každé dvě vteřiny.
Cestou se ukázalo, že hláška se nikdy nedostala do přesměrovaného výstupu:
mimo konzoli drží Python výstup v bloku a pouští ho, až program skončí —
jenže server neskončí. Zkouška binárky u Gitey si logovala do souboru a pak
ho vypisovala, takže celou dobu tiskla prázdno. Řeší to řádkové bufferování
v console.utf8(), kam to patří vedle té kódové stránky.
Venku jsou čtyři soubory na release, tři systémy a k tomu zdrojáky. Když
někdo napíše, že mu něco nefunguje, není jak zjistit, co vlastně pustil.
Verzi zapisuje build.sh do verze.txt, kostky.spec ji přibalí a version.py ji
z rozbalené binárky přečte. Ze zdrojáků má přednost git describe, který ví
i o commitech nad tagem a o rozdělané práci. V CI se na tagu vnucuje
proměnnou, protože runner klonuje jeden commit bez značek.
Hlásí se přes --version, v úvodní hlášce serveru a v patičce každé stránky.
Zkouška v obou workflow ověří, že se do binárky opravdu dostala.
Dokud to běželo jen doma, šlo dice.db v nejhorším smazat. Teď jsou venku
binárky, které si zakládají databázi v %LOCALAPPDATA% a v Library, a ta data
patří cizím lidem — první sloupec, který přibude, na nich prostě nebude.
Verze se drží v PRAGMA user_version. Existující databáze mají nulu a plné
schéma zároveň, což vychází: SCHEMA je samé IF NOT EXISTS, takže se na nich
jen orazítkuje a nic se neztratí.
Databázi z novější verze aplikace radši odmítneme otevřít. Srozumitelná
hláška je lepší než tiše rozbitá data, ke kterým neexistuje záloha.
Bez zamčených verzí si každá stavba stáhne to, co je zrovna nejnovější:
binárka z dneška a binárka z příštího jara obsahují něco jiného a není jak
zjistit co. Zároveň může vydání kterékoli knihovny rozbít build, aniž by se
sáhlo na řádku kódu — a nejspíš zrovna ve chvíli, kdy se tagne release.
Volné seznamy jsou nově v `.in`, zamčené v `.txt`. Rozděleno na tři: běh,
testy a stavba. Pytest se tak přestane instalovat do prostředí, kde se
staví binárka, a PyInstaller má konečně taky zamčenou verzi — ta na podobu
výsledku sahá ze všech nejvíc.
Zůstává, že se verze píšou i v hlavičce PEP 723, jinak by přestalo fungovat
`uv run web.py`. Aby se ta dvě místa nerozešla, hlídá je test.
Windowsová binárka spadla dřív, než stihla vypsat adresu:
print("Počitadlo je dostupné na:")
UnicodeEncodeError: 'charmap' codec can't encode character 'č'
Windows sahá po historické kódové stránce všude, kde výstup není konzole —
přesměrovaný do souboru, puštěný ze skriptu, ve frontě CI. První háček nad
takovým proudem shodí celý program.
Oba vstupní body si teď výstup přepnou na UTF-8. Na konzoli i na ostatních
systémech je to prázdná operace, protože tam je UTF-8 dávno výchozí.
Pojistka errors="replace" je pro zbytek případů: rozsypaný háček je pořád
lepší než spadlý server.
Chytila to zkouška po stavbě, ne uživatel. Test to reprodukuje přes
TextIOWrapper s cp1252, takže se to bez opravy neprojde ani na Linuxu.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PyInstaller neumí křížovou kompilaci — binárku pro každý systém musí
postavit ten systém. Vlastní runner pro Windows a hlavně pro macOS by byl
nepoměr, tak si tyhle stroje půjčujeme od GitHub Actions.
GitHub je jen půjčená dílna, ne druhý domov projektu: repozitář se tam
z Gitey zrcadlí, hotové soubory se posílají zpátky na zdejší release přes
Gitea API a stránka s releasy zůstává jedna. Linux se tam schválně
nestaví; doma to jde proti glibc 2.17 a je to zároveň pojistka, kdyby
GitHub vypadl.
build.sh je společný pro všechny tři systémy, liší se jen tím, že Windows
dává spustitelné soubory venvu do Scripts/ místo bin/. Ořezání symbolů
zůstává jen Linuxu: na macOS by rozbilo podpis, který si PyInstaller sám
přidává a bez kterého se binárka na Apple Silicon vůbec nespustí.
Zkouška po stavbě je stejná jako u linuxové: nastartovat, stáhnout si
stránku i styly a ověřit, že se založila databáze.
Nepodepsané binárky si Gatekeeper ani SmartScreen nenechají líbit, tak je
v README napsané, co s tím — certifikáty za tisíce ročně by na počitadlo
kostek byly nesmysl.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Tabule dosud zbylé adresy jen vypsala, ale naskenovat se dala pouze ta
první. Teď se na ně dá kliknout: vybraná se přesune nahoru velkým písmem,
QR kód se přepne na ni a ta předchozí se objeví v seznamu, takže se dá
kroužit dokola.
Kódy jsou vykreslené všechny předem a přepíná se jen ten viditelný —
žádné doptávání serveru, žádná QR knihovna na klientovi. Aby to stránku
nenafouklo, skládá se SVG ze souvislých úseků místo jednotlivých
čtverečků; tabule se třemi adresami má 23 kB.
Otisk v data-address zahrnuje všechny adresy, ne jen tu první. Když se
změní kterákoli z nich, nabídka i QR kódy jsou k ničemu a tabule se
načte znovu.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Věší se jako druhá příloha ve formátu sha256sum, počítaná nad jménem, pod
kterým se soubor stahuje — aby se dala ověřit rovnou přes
sha256sum -c, bez přejmenovávání.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Matice Python 3.11 až 3.14 — u projektu, který deklaruje >=3.11, se hodí
vědět, že to na všech čtyřech opravdu jede. Pythony obstará uv, na
hostiteli nemusí být žádný.
K pytestu ještě skriptovaná partie v terminálové verzi. Pytest sahá na
core.py, prompty v dice.py nikdo netestoval; tohle projde dvě nuly, třetí
s vynulováním a výhru tak, jak to odehraje člověk.
Runner sdílí pracovní adresář mezi variantami matice, proto max-parallel 1.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Runner běží v host módu, bez dockeru, takže se v něm kontejner na AlmaLinux
spustit nedá. Ukázalo se ale, že kontejner potřeba není: stačí stavět proti
samostatnému CPythonu od uv. Ten je slinkovaný s glibc 2.17 a nic
z hostitele se do binárky nedostane — změřeno objdumpem přes všechno, co
se z ní rozbaluje. Výsledek je tedy přenositelnější než přes AlmaLinux 8
(2.28) a build.sh je o polovinu kratší.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Otagovaný commit postaví binárku na runneru, projede testy, zkusí ji
nastartovat a pověsí ji na release. Nad pull requesty běží totéž bez
posledního kroku, ať se rozbitá stavba pozná dřív než na tagu.
Staví se v kontejneru na AlmaLinux 8 ze stejného důvodu jako build.sh —
kvůli glibc. Záměrně bez hotových akcí z marketplace: na vlastním runneru
tím odpadá starost, jestli je v kontejneru node.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Stáhni a spusť: jednosouborová binárka pro Linux, uvnitř Python, Flask,
šablony i styly. Staví se ./build.sh v kontejneru na AlmaLinux 8, protože
binárka slinkovaná proti glibc z Fedory 44 by nešla spustit nikde se
starším systémem.
Databáze tím dostává dvě různá místa. Ze zdrojáků zůstává dice.db
v pracovním adresáři, ať se dá mít víc sad vedle sebe. Z binárky jde do
~/.local/share/kostky/ — binárka se rozbaluje do dočasného adresáře
a pouští se odkudkoli, takže relativní cesta by databázi rozsypala po
disku. DICE_DB přebije obojí.
Server teď cestu k databázi vypisuje při startu, ať se na ni nemusí ptát.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Trojice venv/pip/python byla zbytečná ceremonie pro appku, která se pouští
jednou za herní večer.
- web.py i dice.py si nesou závislosti v hlavičce podle PEP 723, takže
je uv obstará sám a není co instalovat ani aktivovat
- pytest.ini staví kořen repa na pythonpath, takže testy jdou spustit
i mimo připravené prostředí
- README nabízí uv jako hlavní cestu, venv a systémové balíčky jako
záložní
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Detekce vracela jedinou adresu podle výchozí trasy. Když ta nevede tam,
kam je připojený telefon, QR kód míří do prázdna a nezbývá než sahat do
konfigurace. Při ladění se ukázalo i to, že záložní větev může vrátit
127.0.0.1, tedy QR kód na localhost.
- net.py hledá adresy všech rozhraní přes if_nameindex a ioctl, se zálohou
přes getaddrinfo; DICE_HOST má poslední slovo
- řadí se podle rozsahu adresy a obecného typu rozhraní, ne podle seznamu
konkrétních jmen: výchozí trasa, místní sítě, tailnet, virtuální sítě
- loopback a link-local vypadnou, nic dalšího se nezahazuje — o tom, co
funguje, rozhoduje člověk u stolu
- tailnet adresu vědomě necháváme: funguje i napříč sítěmi
- adresy se hledají při každém načtení; když se notebook přesune na jinou
síť, tabule to pozná podle data-address a načte se znovu
- když se nenajde nic, tabule řekne, co s tím, místo QR kódu naslepo
- 20 testů nad klasifikací a řazením, nezávislých na aktuální síti
- README doplněn o řešení potíží s připojením
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- rekordy: nejvyšší tah, nejvyšší konečné skóre, nejrychlejší výhra
- kariéra: počet her, výher, úspěšnost, průměrné pořadí, průměr na tah
a kolikrát koho postihlo vynulování
- do statistik jdou jen dohrané hry, nedohrané a opuštěné se ignorují
- celkové skóre počítá SQL stejným pravidlem jako core.Game.totals(),
tedy součet tahů po posledním vynulování; testem ověřeno, že se obě
cesty shodují
- vědomě chybí celkový součet bodů napříč hrami — cílové skóre je u každé
hry jiné, metrika by odměňovala jen toho, kdo hrál nejvíc
- README se spuštěním a přehledem modulů
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gitea-actions
david-spacil