Aggiornamento main #14

2026-03-22T16:25:35+01:00

Alessio commented

2026-03-22 16:25:35 +01:00

No description provided.

Alessio added 5 commits 2026-03-22 16:25:36 +01:00

[Fix] Correzione versioning CI/CD: fetch completo storia Git per MinVer 4262fd6d71

Aggiunto fetch-depth: 0 al checkout in tutti i job dei workflow GitHub Actions e Gitea Actions.
Rimosso --depth 1 dal clone manuale del job Windows in Gitea.
MinVer necessita della storia completa per risalire ai tag Git e calcolare la versione corretta.
Senza questa correzione la versione risultava sempre 2.1.0 (fallback hardcoded).
Aggiornato anche il valore di fallback da 2.1.0 a 2.3.2.

[Fix] Passa versione MinVer come build-arg al Docker per evitare errore MINVER1001 c15e6c9065

Il problema era che MinVer veniva eseguito dentro il container Docker dove la
directory .git non esiste, causando il warning MINVER1001 e l'uso di 0.0.0-alpha.0
(poi sostituito dal fallback hardcoded 2.1.0).

Soluzione:
- La versione viene calcolata sul runner CI/CD (dove git e' disponibile)
- Esportata come variabile d'ambiente APP_VERSION via GITHUB_ENV
- Passata al Docker build tramite --build-arg APP_VERSION
- Nei Dockerfile aggiunto ARG APP_VERSION e /p:MinVerVersionOverride per imporla
  a MinVer senza che tenti di accedere a git (assente nel container)
- ARG ridichiarato dopo ogni FROM in multi-stage build (comportamento Docker)

[Fix] Refactoring calcolo versione CI/CD: usa git describe invece di dotnet msbuild e125e758fb

Problemi risolti:
- GitHub Windows: errore PowerShell 'Missing closing )' causato da (cd Dir; cmd)
  sintassi bash non valida in PowerShell
- GitHub Linux: versione 1.0.0 invece di 2.3.2 perche il tag v2.3.2 esiste solo
  su Gitea e non su GitHub, quindi MinVer trovava il vecchio tag v1.0.0

Soluzione:
- Sostituito dotnet msbuild -getProperty:Version con git describe --tags --abbrev=0
  che e lo strumento nativo Git per ottenere l'ultimo tag raggiungibile
- Funziona identicamente su Linux (bash) e Windows (PowerShell)
- Non richiede dotnet installato ne accesso al .git dentro Docker
- Rimosso il dotnet build intermedio sul runner (non piu necessario)
- Corretti i percorsi version.json: ora usa Data_Coupler/wwwroot/version.json
  dal root del repo invece di wwwroot/ relativo dopo cd

[Fix] GitHub Actions: aggiunge generazione version.json prima del Docker build 46fc21bf7b

Il workflow GitHub non generava version.json sul runner prima del build,
quindi Docker copiava il file statico del repository (con versione vecchia 2.1.0).

La Gitea Actions usava gia questo approccio correttamente.

Fix applicato: lo step 'Calcola versione' ora genera anche version.json in
Data_Coupler/wwwroot/version.json per entrambi i job Linux e Windows,
con versione, commit SHA, branch, data build e ambiente (GitHub Actions).

Il VersionService legge version.json all'avvio per display nell'UI.

[Fix] Dockerfile.windows: aggiunge ContinuousIntegrationBuild=true a dotnet build e publish

Build and Push Docker Images / Build Linux Container (push) Successful in 6m9s

Details

Build and Push Docker Images / Create Multi-Platform Manifest (push) Has been cancelled

Details

Build and Push Docker Images / Build Windows Container (push) Has been cancelled

Details

f1f75d59ac

Senza questo flag il target GenerateVersionJson nel .csproj veniva eseguito
dentro il container Docker Windows dove:
- Non esiste .git (fatal: not a git repository)
- version.json copiato da COPY e' read-only o protetto
→ MSB3491: Access to the path '...\wwwroot\version.json' is denied

Il Dockerfile Linux aveva gia /p:ContinuousIntegrationBuild=true.
La condizione nel .csproj e':
  Condition="'' != 'true' AND '' != 'true'"
quindi con il flag il target viene saltato e version.json usa quello
generato dal workflow prima del docker build.

Alessio merged commit f1f75d59ac into main

2026-03-22 16:25:41 +01:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Alessio/Data-Coupler#14