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:
Claude Opus 5
@@ -0,0 +1,114 @@
|
||||
# Catena di verifica, pacchetto e rilascio
|
||||
|
||||
Tutto quello che serve a controllare, impacchettare e pubblicare Encelado sta in questa
|
||||
cartella. La radice del progetto non contiene script.
|
||||
|
||||
È la stessa catena di [Mimante/AutoBidder](http://192.168.30.23:3000/Alby96/Mimante),
|
||||
adattata a una soluzione con più progetti. Le differenze sono tre, tutte segnate sul
|
||||
posto in `Release.proj`:
|
||||
|
||||
| | AutoBidder | Encelado |
|
||||
|---|---|---|
|
||||
| Dove sta la versione | `AutoBidder.csproj` | `Directory.Build.props`, ereditato da tutti i progetti |
|
||||
| Cosa produce `dotnet publish` | un eseguibile unico | una cartella: l'app legge `encelado.json` accanto a sé |
|
||||
| Copia portabile allegata | il solo `.exe` | uno zip della cartella |
|
||||
| Cosa rigioca `Backtest` | i dossier delle aste | serie storiche di prezzi |
|
||||
|
||||
| File | Cos'è |
|
||||
|---|---|
|
||||
| `Release.proj` | La catena. Un solo file MSBuild, nessuno script. |
|
||||
| `Encelado.iss` | Lo script di Inno Setup. Non si compila a mano: lo lancia `Release.proj`. |
|
||||
| `gitea.example.json` | Modello per `gitea.json` (che è escluso dal controllo di versione). |
|
||||
|
||||
## Da VS Code
|
||||
|
||||
**Terminale ▸ Esegui attività…**
|
||||
|
||||
| Attività | Cosa fa |
|
||||
|---|---|
|
||||
| `verifica` | Compila e lancia i test. |
|
||||
| `backtest` | Rigioca una serie storica di prezzi. |
|
||||
| `crea installatore` | Chiede la versione, verifica, pubblica, esegue Inno Setup. |
|
||||
| `crea installatore (senza rieseguire i test)` | Solo pubblicazione e installatore. |
|
||||
| `rilascia su Gitea` | Tutto quanto sopra, più tag e release con i file allegati. |
|
||||
|
||||
## Da riga di comando
|
||||
|
||||
```powershell
|
||||
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 -p:Note="Cosa cambia"
|
||||
|
||||
# Il backtest vuole un file di dati
|
||||
dotnet msbuild build/Release.proj -t:Backtest -p:Dati="C:\dati\btcusd.csv"
|
||||
dotnet msbuild build/Release.proj -t:Backtest -p:Dati="..." -p:Comando=frequency
|
||||
```
|
||||
|
||||
| Proprietà | Predefinito | A cosa serve |
|
||||
|---|---|---|
|
||||
| `Versione` | vuoto | Vuoto = incrementa la minor (3.2.0 → 3.3.0). Altrimenti la scrive, se ha la forma `X.Y.Z`. |
|
||||
| `Note` | vuoto | Note di rilascio. |
|
||||
| `SaltaVerifica` | `false` | Non rieseguire i test. |
|
||||
| `Sovrascrivi` | `false` | Sostituisci una release Gitea con lo stesso tag. |
|
||||
| `Bozza` | `false` | Crea la release come bozza. |
|
||||
| `ConsentiModifiche` | `false` | Tagga anche con l'albero sporco. Serve saperlo. |
|
||||
| `Dati` | — | Il CSV da rigiocare. Obbligatorio per `Backtest`. |
|
||||
| `Comando` | `split` | `split`, `walk`, `frequency`, `costs`, `sweep`, `explore`. |
|
||||
| `Barre` | `1d` | Ampiezza delle barre nel backtest. |
|
||||
|
||||
## Chi chiede la versione
|
||||
|
||||
MSBuild non può chiedere niente a nessuno: è un motore di compilazione. La domanda la fa
|
||||
l'attività di VS Code (`inputs` in `.vscode/tasks.json`) e passa la risposta in
|
||||
`-p:Versione=`. Lasciando il campo vuoto si prende la minor successiva, che è il caso
|
||||
normale di fine sessione.
|
||||
|
||||
**La versione arriva dal tag e non viene scritta da nessuna parte.** `dotnet publish` la
|
||||
riceve come proprietà da riga di comando, che è globale e vince su quella dichiarata in
|
||||
`Directory.Build.props`. Tag, eseguibile, installatore e release portano quindi lo stesso
|
||||
numero per costruzione.
|
||||
|
||||
Il tag si crea **in fondo**, quando l'installatore esiste davvero. Il contrario sembra più
|
||||
naturale — decidi il numero, poi costruisci — ma lascia dietro un tag quando la verifica
|
||||
fallisce, e il tentativo dopo riparte da lì: il numero sale senza che sia mai esistito un
|
||||
pacchetto con quella versione.
|
||||
|
||||
## Gitea
|
||||
|
||||
Servono quattro valori. Le variabili d'ambiente hanno la precedenza sul file, così una
|
||||
macchina condivisa può rilasciare senza scrivere un token su disco:
|
||||
|
||||
- `GITEA_URL`, `GITEA_OWNER`, `GITEA_REPO`, `GITEA_TOKEN`
|
||||
- oppure `build/gitea.json`, copiato da `gitea.example.json`
|
||||
|
||||
Il token si crea in Gitea da *Impostazioni ▸ Applicazioni ▸ Genera nuovo token*, con il
|
||||
permesso `repository: read and write`.
|
||||
|
||||
Il token non passa mai dalla riga di comando: sta in un file di configurazione di curl,
|
||||
cancellato subito dopo il rilascio. Gli `Exec` hanno `EchoOff` perché un registro di
|
||||
compilazione è la classica cosa che si incolla in una chat.
|
||||
|
||||
Nella release vengono caricati **sia l'installatore sia la copia portabile**: chi non
|
||||
vuole installare niente deve continuare a poter scaricare l'applicazione e basta.
|
||||
|
||||
## Una trappola già pagata
|
||||
|
||||
`dotnet test` e `dotnet publish` lanciati **da dentro** MSBuild ereditano l'ambiente del
|
||||
processo padre. La compilazione WPF crea un progetto temporaneo (`_wpftmp.csproj`) e con
|
||||
`MSBUILD_EXE_PATH` puntata al build in corso non genera più le classi parziali dello XAML:
|
||||
si ottengono decine di errori su membri che esistono benissimo.
|
||||
|
||||
Per questo gli `Exec` azzerano `MSBUILD_EXE_PATH` e `MSBuildLoadMicrosoftTargetsReadOnly`.
|
||||
**Solo quelle due**: la ricetta che gira in rete azzera anche `MSBuildExtensionsPath` e
|
||||
`MSBuildSDKsPath`, e così il figlio perde la posizione dell'SDK — *«l'SDK Microsoft.NET.Sdk
|
||||
specificato non è stato trovato»*. Serve isolare il motore, non nascondergli dove abita.
|
||||
|
||||
I test girano in una cartella a parte (`%TEMP%\Encelado.Verifica`) perché l'applicazione
|
||||
può essere aperta mentre si lavora e tiene bloccato `Encelado.exe`: senza, la compilazione
|
||||
si ferma su MSB3027.
|
||||
|
||||
## Prerequisiti
|
||||
|
||||
- .NET SDK 10
|
||||
- [Inno Setup 6](https://jrsoftware.org/isinfo.php) — `winget install -e --id JRSoftware.InnoSetup`
|
||||
- `curl` e `git`, entrambi di serie in Windows 11
|
||||
Reference in New Issue
Block a user