Unifica la catena di rilascio con Mimante/AutoBidder

La generazione del setup, il versionamento e il caricamento su Gitea passano
ora da un solo file MSBuild in build/Release.proj, com'e' gia' per AutoBidder,
al posto dello script PowerShell make-installer.ps1.

Il cambiamento di sostanza e' da dove viene la versione: dal tag git, non piu'
da Directory.Build.props. Il numero arriva a dotnet publish come proprieta' da
riga di comando, quindi tag, eseguibile, installatore e release lo portano
uguale per costruzione invece che per disciplina. Il tag si crea in fondo, a
installatore esistente, e non si crea affatto se l'albero e' sporco: un giro
andato male non lascia dietro un tag per una versione mai costruita.

Tre adattamenti rispetto ad AutoBidder, segnati sul posto: la versione sta in
Directory.Build.props e non nel csproj; la pubblicazione produce una cartella
e non un eseguibile unico, perche' l'app legge encelado.json accanto a se',
quindi la copia portabile allegata alla release e' uno zip; il target Backtest
rigioca serie storiche di prezzi invece dei dossier delle aste.

Il setup si chiama Encelado_<versione>.exe e la pubblicazione ora fallisce se
nella cartella finiscono sorgenti o simboli di debug.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-08-05 10:26:34 +02:00
co-authored by Claude Opus 5
parent ebc391eadd
commit 2b4c53ec70
10 changed files with 1147 additions and 446 deletions
+38 -21
View File
@@ -45,49 +45,66 @@ prima — niente variabili d'ambiente, niente file da editare.
---
## Installer
## Verifica, pacchetto e rilascio
Per portare Encelado su un'altra macchina serve un file solo:
**È la stessa catena di [Mimante/AutoBidder](http://192.168.30.23:3000/Alby96/Mimante):
un solo file MSBuild in `build/Release.proj`, nessuno script.** I dettagli stanno in
[`build/README.md`](build/README.md).
Da VS Code: **Terminale ▸ Esegui attività…**
| Attività | Cosa fa |
|---|---|
| `verifica` | Compila e lancia i test. |
| `backtest` | Rigioca una serie storica di prezzi. |
| `crea installatore` | Verifica, pubblica, esegue Inno Setup, crea il tag. |
| `crea installatore (senza rieseguire i test)` | Solo pubblicazione e installatore. |
| `rilascia su Gitea` | Tutto quanto sopra, più tag e release con i file allegati. |
```powershell
.\build\make-installer.ps1
dotnet msbuild build/Release.proj -t:Verifica
dotnet msbuild build/Release.proj -t:Pacchetto
dotnet msbuild build/Release.proj -t:Rilascia -p:Versione=3.3.0
```
Da VS Code: **Ctrl+Shift+P → Run Task → installer**.
**La versione viene dal tag git, e da nient'altro.** Non viene mai riscritto un file:
il numero arriva a `dotnet publish` come proprietà da riga di comando, quindi tag,
eseguibile, installatore e release portano lo stesso numero per costruzione, non per
disciplina. Il `<Version>` in `Directory.Build.props` resta quello delle compilazioni
di sviluppo — è il numero che vedi nella finestra mentre lavori — e serve solo come
seme al primissimo rilascio, quando non esiste ancora nessun tag.
Lo script esegue i test, pubblica in `win-x64` e compila `installer\Encelado.iss`,
lasciando `artifacts\installer\Encelado-Setup-<versione>.exe` — circa 45 MB. Al primo
utilizzo installa Inno Setup con `winget` se non lo trova; dopo non serve più.
Il tag viene creato **in fondo**, a installatore esistente: un giro andato male non
lascia dietro un tag per una versione che non è mai stata costruita. E non viene creato
affatto se ci sono modifiche non committate, perché indicherebbe uno stato non
ricostruibile.
Chi riceve quel file ci fa doppio clic e basta: nessuna richiesta di privilegi,
nessun prerequisito da installare prima.
Il pacchetto esce in `bin/installer/`:
| | |
|---|---|
| `Encelado-<versione>-setup.exe` | L'installatore, ~47 MB |
| `Encelado-<versione>-portabile.zip` | La cartella pubblicata, per chi non vuole installare niente |
| Destinazione | `%LOCALAPPDATA%\Programs\Encelado` |
| UAC | nessuna richiesta |
| Runtime .NET | incorporato, non serve installarlo |
| Menu Start e desktop | collegamenti creati, disinstallazione dal pannello di controllo |
**Perché per utente e non in `Programs Files`.** Non è per evitare l'UAC. Encelado
**Perché per utente e non in `Program Files`.** Non è per evitare l'UAC. Encelado
scrive log, diario operazioni e CSV di analisi accanto al proprio eseguibile: dentro
`C:\Program Files` quelle scritture fallirebbero, e siccome il logger degrada in
silenzio piuttosto che bloccare il bot, te ne accorgeresti solo cercando i log per
capire cosa è successo. Per questo `PrivilegesRequired=lowest` non è sovrascrivibile.
**Aggiornamenti.** Reinstallare sopra una versione precedente **non** tocca il tuo
`encelado.json`: le modifiche a rischio e verbosità sopravvivono. Accanto trovi
sempre `encelado.default.json` aggiornato, per confrontare la tua configurazione con
i valori di fabbrica. Se l'applicazione è in esecuzione, l'installer la chiude.
`encelado.json`: le modifiche fatte dalla scheda Impostazioni sopravvivono. Accanto
trovi sempre `encelado.default.json` aggiornato, per confrontare la tua configurazione
con i valori di fabbrica. Se l'applicazione è in esecuzione, l'installatore la chiude.
**Disinstallazione.** Rimuove programma e log. Le credenziali Alpaca stanno altrove
(`%LOCALAPPDATA%\Encelado`) e vengono cancellate solo se rispondi Sì alla domanda
esplicita — il default è No, così reinstallare non costringe a reinserire le chiavi.
In modalità silenziosa la domanda non viene posta e le credenziali restano.
Con `-FrameworkDependent` l'installer scende a ~2 MB, ma sulla macchina di
destinazione deve già esserci il .NET 10 Desktop Runtime.
---
## Cosa c'è nella finestra
@@ -549,15 +566,15 @@ src/
Theme.xaml tavolozza, stili e template dei controlli
Assets/ icona multi-risoluzione (16→256 px)
tests/
Encelado.Tests/ 250 test
Encelado.Tests/ 309 test
tools/
Encelado.Backtest/ banco di prova, non fa parte dell'applicazione
config/
encelado.json la configurazione consegnata
build/
make-installer.ps1 pubblica e impacchetta
installer/
Encelado.iss script Inno Setup
Release.proj verifica, pacchetto e rilascio — un file MSBuild, nessuno script
Encelado.iss script Inno Setup, lanciato da Release.proj
gitea.example.json modello per gitea.json, che resta fuori dal repository
```
### Il banco di prova