Commit Graph
7 Commits
Author SHA1 Message Date
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 e3d56f4c22 Binárka má vědět, která je
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.
2026-08-22 18:26:32 +02:00
gitea-actions 3af8fe22ef Zamknout závislosti
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.
2026-08-22 18:22:35 +02:00
gitea-actionsandClaude Opus 5 42f454f754 k binárce i kontrolní součet
binárka / linux (pull_request) Successful in 10s
testy / pytest (3.11) (pull_request) Successful in 0s
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
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>
2026-08-21 17:45:00 +02:00
gitea-actionsandClaude Opus 5 b4864981ad runner potřebuje binutils, doinstaluje si je sám
binárka / linux (pull_request) Successful in 14s
PyInstaller hledá objdumpem, na kterých knihovnách binárka visí. Runner
v host módu ho nemá — je to jediné, co musí být na hostiteli, zbytek si
obstará uv.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 17:24:37 +02:00
gitea-actionsandClaude Opus 5 8aa54dc7a0 stavba bez kontejneru, proti Pythonu od uv
binárka / linux (pull_request) Failing after 4s
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>
2026-08-21 17:23:09 +02:00
gitea-actionsandClaude Opus 5 cb39036724 release se staví sám z tagu
binárka / linux (pull_request) Failing after 0s
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>
2026-08-21 17:18:39 +02:00