6 Commits
Author SHA1 Message Date
gitea-actions a6c94e239b Zaříznout stará jména kostky
binárka / linux (pull_request) Successful in 11s
image / image (pull_request) Successful in 18s
testy / pytest (3.11) (pull_request) Successful in 1s
testy / pytest (3.12) (pull_request) Successful in 0s
testy / pytest (3.13) (pull_request) Successful in 0s
testy / pytest (3.14) (pull_request) Successful in 1s
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
2026-08-23 23:09:15 +02:00
gitea-actions 7449c01b14 Sjednotit pojmenování: kostky → dice-counter
binárka / linux (pull_request) Failing after 10s
image / image (pull_request) Successful in 7s
testy / pytest (3.11) (pull_request) Successful in 1s
testy / pytest (3.12) (pull_request) Successful in 1s
testy / pytest (3.13) (pull_request) Successful in 1s
testy / pytest (3.14) (pull_request) Successful in 1s
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
2026-08-23 22:29:58 +02:00
gitea-actions 4ffd7d3c9d Verzovat schéma databáze
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.
2026-08-22 18:23:38 +02:00
gitea-actionsandClaude Opus 5 26338bfa29 Adresy a data podle systému, ne podle Linuxu
Než začneme rozdávat binárky pro macOS a Windows, musí se na nich chovat
rozumně to, co dosud počítalo s Linuxem.

Adresy rozhraní se hledaly linuxovým ioctl. Na Windows chybí fcntl, na
macOS to číslo znamená něco jiného, takže obojí propadlo až na poslední
zálohu přes hostname — a ta na macOS vrátí jednu adresu. Tabule by tam
nabídla jedinou volbu, přesně to, co jsme minule opravovali. Přibyla
mezizáloha přes ifconfig; spouští se jen tam, kde ioctl nic nenašel,
takže na Linuxu se neplatí nic. Parsování je zvlášť jako čistá funkce,
ať jde otestovat i bez macOS pod rukama.

Databáze z binárky mířila do XDG adresáře na všech systémech. Na Windows
by to znamenalo C:\Users\...\.local\share\, což tam nikdo nečeká. Teď se
volí podle systému: LOCALAPPDATA, Library/Application Support, XDG.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 13:13:41 +02:00
gitea-actionsandClaude Opus 5 fcfa0e489b binárka ke stažení a jasné místo pro databázi
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>
2026-08-21 17:17:09 +02:00
gitea-actionsandClaude Opus 5 a45a82ae0e storage: SQLite s arkádovou identitou hráčů
Ručně psané SQL nad pěti tabulkami, žádné ORM.

- hry ukazují na players.id, nikdy na jméno, takže se přejmenování
  propíše i do starých her
- párování hráčů napříč hrami přes normalizovaný klíč (trim, casefold),
  plus slučování pro případ překlepu
- zapisuje se každý tah hned, ne až na konci — rozehraná hra se po pádu
  serveru najde podle stavu a dá se v ní pokračovat
- součty se neukládají nikde, stav hry se rekonstruuje načtením tahů
- časy jako ISO text, sqlite3 vlastní adaptéry pro datetime zavrhl

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 18:47:08 +02:00