Repro conteneur : fiabiliser le téléchargement du SDK Windows (xwin) et finaliser la preuve inter-machines

[Akmot9]

Note

Statut synchronisé le 08/08/2026 sur main@789bee92 — implémentation livrée, preuve locale ↔ CI restante.

Acquis : le toolchain Windows est épinglé, le rebuild applicatif est hors réseau et le run 30493190217 prouve quatre builds CI cross identiques. Docker 29.6.2 est maintenant disponible sur le poste local.

Reste : exécuter deux builds locaux conteneurisés d’un même commit, extraire leur SHA-256 puis relancer repro-container.yml sur ce commit avec windows_reference_sha256. La fermeture exige l’égalité du hash local avec les quatre hashes CI.

Le contenu détaillé ci-dessous reste la référence ; ce bandeau prévaut lorsqu’il décrit un état historique.

---

Statut — implémentation livrée, preuve CI inter-machines acquise

Mise à jour du 29/07/2026 sur main :

• 0bbe7de : durcissement complet du build Windows reproductible ;
• 42726ae : sélection explicite du toolchain Rust déjà installé pendant le build hors réseau ;
• preuve GitHub Actions : https://github.com/Sonar-team/Sonar_desktop_app/actions/runs/30493190217

Acquis

• cargo-xwin 0.23.0 et xwin 0.9.0 via son lockfile amont ;
• manifeste Visual Studio 17, SDK 10.0.26100, CRT 14.44.17.14 et architecture x86_64 épinglés ;
• retries complets du téléchargement xwin ;
• couche windows-toolchain indépendante des sources applicatives ;
• compilation applicative exécutée avec RUN --network=none ;
• frontend Dockerfile et image Rust verrouillés par version et digest ;
• plateforme hôte Docker fixée à linux/amd64 ;
• deux runners hébergés, deux builds cross chacun, avec comparaison obligatoire des quatre manifests ;
• build Windows natif reproductible et double build Linux également validés.

Les quatre builds Windows cross du commit 42726ae produisent exactement :

5037d8f9b76401a60f8fbf5412af12a95bb793d7846be945b4e8e9bc62395ddd  ./windows/sonar.exe

Reliquat avant fermeture — preuve locale ↔ CI au même commit

Le workflow accepte une référence locale et Docker 29.6.2 est maintenant disponible sur le poste actuel. Il reste donc à produire un hash local conteneurisé pour un commit précis :

REF=<commit> RUNS=2 NO_CACHE=1 PLATFORM=windows OUT=repro-windows \
  ./script/release/repro-build-container.sh
awk '$2 == "./windows/sonar.exe" { print $1 }' \
  repro-windows/run1/SHA256SUMS

Relancer ensuite .github/workflows/repro-container.yml sur le même commit avec ce hash dans windows_reference_sha256. Le comparateur exigera son égalité avec les quatre hashes CI.

L'issue reste ouverte uniquement pour cette dernière preuve locale ↔ CI. Le bootstrap initial de windows-toolchain reste une opération en ligne vers le manifeste Visual Studio et le CDN Microsoft ; le rebuild applicatif, lui, est désormais prouvé hors réseau.

[Akmot9]

Divergence inter-machines confirmée (28/07) — le reliquat 2 n'est plus théorique :

• local, commit 3840788, 3 builds sur 2 jours : 834cd9ba… (stable) ;
• CI, même commit, 2 builds : 95c6a1c5… (stable).

Chaque environnement est auto-cohérent mais ils divergent entre eux. Cause identifiée : cargo-xwin télécharge « latest » pour le CRT et le SDK Windows par défaut (XWIN_SDK_VERSION/XWIN_CRT_VERSION non épinglées) — le CDN Microsoft a servi des versions différentes aux deux machines. Le cache splatté ne conserve pas les numéros exacts (STL 143 / gén. Win10 seulement).

Plan de correction :

1. relancer un build avec RUST_LOG=info (ou xwin standalone --manifest-version) sur un bon réseau pour lire les versions résolues ;
2. épingler XWIN_VERSION, XWIN_SDK_VERSION, XWIN_CRT_VERSION en build-args du stage windows-builder + XWIN_HTTP_RETRIES (3 blocages réseau silencieux observés) ;
3. re-prouver local == CI au même commit ;
4. option long terme cohérente air-gap : pré-splatter le SDK dans une couche dédiée de l'image (le docker save l'emporte alors, zéro téléchargement au rebuild).

Diagnostic annexe : les « blocages CDN » du 27 au soir étaient une panne DNS des conteneurs buildkit sur réseau hotspot téléphone ; --network=host contourne.

[Akmot9]

Le correctif final 42726ae résout l'échec observé de rustup dans la couche hors réseau.

Le run https://github.com/Sonar-team/Sonar_desktop_app/actions/runs/30493190217 est entièrement vert : Linux, Windows natif, machine-a, machine-b et comparaison inter-machines. Les quatre builds Windows cross ont le SHA-256 identique 5037d8f9b76401a60f8fbf5412af12a95bb793d7846be945b4e8e9bc62395ddd.

Je garde l'issue ouverte uniquement parce que windows_reference_sha256 était vide : il manque encore la comparaison d'un hash local conteneurisé avec ces quatre hashes CI au même commit.

[Akmot9]

Preuve locale conteneurisée produite — 08/08/2026

Le reliquat demandait un hash local conteneurisé. Il est produit, sur le poste local (Docker 29.6.2), avec la commande de l'issue :

REF=v4.12.1 RUNS=2 NO_CACHE=1 PRUNE=0 PLATFORM=windows OUT=repro-out \
  ./script/release/repro-build-container.sh

Commit construit : fbe31193921e5b14eeef7ce2ba84a9995912436c (tag v4.12.1).

run1: 41aed95469e791927da1f6c0ce0933afabe1de4b0fe3acb3029df0d3e829ab5f  ./windows/sonar.exe
run2: 41aed95469e791927da1f6c0ce0933afabe1de4b0fe3acb3029df0d3e829ab5f  ./windows/sonar.exe

Attention à la comparaison : les quatre hashes CI de ce fil (5037d8f9…) portent sur le commit 42726ae0, pas sur celui-ci. Ces deux valeurs ne sont donc pas comparables entre elles. Pour clore, relancer repro-container.yml sur fbe31193 avec windows_reference_sha256=41aed95469e791927da1f6c0ce0933afabe1de4b0fe3acb3029df0d3e829ab5f.

Validation fonctionnelle du binaire cross

Le binaire produit n'avait jamais été exécuté sur une machine Windows. Fait, sur une VM Windows 11 Pro 26200 avec Npcap 1.88 en mode compatible WinPcap :

• script/ci/validate-windows-release-binary.ps1 → exit 0, « PE structure and direct wpcap.dll import validated » ;
• sonar.exe --sonar-smoke-test → SONAR_SMOKE_DEVICE=\Device\NPF_{…}, SONAR_STARTUP_VALIDATION=OK, exit 0.

Le risque « les import libs Npcap ne tiennent pas sous cargo-xwin » est donc levé, pas seulement à la compilation mais à l'exécution.

Le bundling NSIS cross fonctionne

Le Dockerfile note « Binaire seul (--no-bundle) : le bundling NSIS cross reste un chantier séparé (#119) » — or #119 est close. Testé aujourd'hui en retirant --no-bundle au profit de --bundles nsis :

• deux builds indépendants (--no-cache-filter windows-builder sur le second) produisent le même installateur : dc38f1191ff21addd3e4c232bf7f05852dc93392a38861c99f79508c89f353e8, 4 285 066 octets ;
• makensis utilisé : /usr/bin/makensis v3.11-1, celui déjà épinglé dans windows-toolchain ;
• cet installateur s'installe en silencieux sur la VM (/S, exit 0) et l'application installée repasse le smoke test (SONAR_STARTUP_VALIDATION=OK).

Un seul obstacle au mode hors réseau : le bundler télécharge nsis_tauri_utils.dll v0.5.3 et le dépose dans /root/.cache/tauri/NSIS/Plugins/x86-unicode/additional/. Avec RUN --network=none, l'étape échoue sur Temporary failure in name resolution. Le précharger dans la couche windows-toolchain (version épinglée + somme de contrôle, comme Node) suffirait à préserver la propriété « rebuild applicatif hors réseau ».

Mes deux runs ci-dessus avaient le réseau ouvert : ils prouvent le déterminisme, pas encore l'autonomie.

Fins de ligne — corrigé par 789bee9

Trouvé en comparant un build natif Windows et un build conteneur du même tag : sans eol=lf explicite, les sources frontend tombaient sous * text=auto et un checkout Windows (core.autocrlf=true) les matérialisait en CRLF. Vite embarquait alors un contenu différent, à commit et versions d'outils identiques.

Mesuré sur une même machine, à la même minute :

CRLF -> assets/index-30IFmrIC.js (445337 o)
LF   -> assets/index-BvJNXkwD.js (445337 o)

Sans impact sur les preuves de ce fil — tous les builds conteneurisés sont sous Linux, donc en LF, et cohérents entre eux. En revanche c'est ce qui rendait un binaire natif Windows et un binaire conteneur définitivement incomparables. Corrigé par 789bee92.

Reste à faire

1. Relancer repro-container.yml sur fbe31193 avec la référence locale ci-dessus → clôture de cette issue.
2. Précharger nsis_tauri_utils.dll dans windows-toolchain et exporter bundle/nsis/*.exe → mérite probablement son propre ticket, Make NSIS setup.exe artifact reproducible #119 étant close.
3. Décider la bascule du job Windows de publish.yml sur le chemin conteneur. Contexte utilisateur : des clients demandent à recompiler chez eux et à retrouver l'empreinte publiée, ce que le build natif windows-2022 ne permettra jamais. À prévoir : la référence d'empreinte change, et les contrôles Windows sont à rebaser dessus.

[Akmot9]

Preuve locale ↔ CI établie au même commit — reliquat levé

Le reliquat décrit dans le bandeau du 08/08 était : « exécuter deux builds locaux conteneurisés d'un même commit, extraire leur SHA-256 puis relancer repro-container.yml sur ce commit avec windows_reference_sha256 ». C'est fait.

1. Deux builds locaux conteneurisés

Docker 29.6.2, poste local, commande exacte de l'issue :

REF=789bee92 RUNS=2 NO_CACHE=1 PLATFORM=windows OUT=repro-windows \
  ./script/release/repro-build-container.sh

binaire run1 : 41aed95469e791927da1f6c0ce0933afabe1de4b0fe3acb3029df0d3e829ab5f
binaire run2 : 41aed95469e791927da1f6c0ce0933afabe1de4b0fe3acb3029df0d3e829ab5f
OK : 2 builds conteneurisés indépendants, binaire identique

Durée : ~5 minutes une fois la couche xwin en cache.

2. Contre-épreuve sur le commit de référence de l'issue

Même opération sur 42726ae037b0bb94428b9a7f73ca5d785b0bfcf5 :

binaire run1 : 5037d8f9b76401a60f8fbf5412af12a95bb793d7846be945b4e8e9bc62395ddd
binaire run2 : 5037d8f9b76401a60f8fbf5412af12a95bb793d7846be945b4e8e9bc62395ddd

Soit exactement le hash que l'issue documente pour les quatre builds CI de ce commit. La correspondance locale ↔ CI tient donc sur deux commits distincts, à un mois d'intervalle.

3. Comparateur CI mécanisé — run 31307469790

repro-container.yml relancé sur main@789bee92 avec windows_reference_sha256=41aed954…. Les cinq jobs sont verts, et le comparateur ne se contente pas d'un vert global :

EXPECTED_WINDOWS_SHA256 : 41aed95469e791927da1f6c0ce0933afabe1de4b0fe3acb3029df0d3e829ab5f
machine-a/run1/SHA256SUMS : 41aed954…ab5f
machine-a/run2/SHA256SUMS : 41aed954…ab5f
machine-b/run1/SHA256SUMS : 41aed954…ab5f
machine-b/run2/SHA256SUMS : 41aed954…ab5f
OK : sonar.exe identique entre les runners CI et la machine locale

Jobs verts : container Linux (2 builds), natif Windows (repro-check.ps1), container Windows cross machine-a et machine-b, comparateur inter-machines.

Ce que cela ne prouve pas

• La machine locale et les runners GitHub sont tous deux linux/amd64. L'égalité est prouvée entre machines, pas entre architectures hôtes — ce que le pinning DOCKER_BUILD_PLATFORM rend d'ailleurs délibéré.
• La couche xwin (SDK/CRT Microsoft) reste en cache entre les runs, par conception du --no-cache-filter windows-builder : c'est la couche applicative qui est rejouée. La fiabilisation du téléchargement xwin, l'autre volet du titre, est couverte par le pinning et les retries déjà en place, non par cette exécution.
• Rien ici ne concerne le DMG (Make DMG artifact reproducible or document deterministic alternative #120), toujours ouvert.

Le critère de fermeture — « l'égalité du hash local avec les quatre hashes CI » — est atteint et mécanisé. Je propose la fermeture.