Docs §16.bis : publish-release.py référencé (les 2 APK dans UNE invocation) ; gitea-release.py documenté pour le corps seul

This commit is contained in:
Siphonight 2026-09-06 10:52:59 +02:00
parent f5e58364a3
commit 88c365f4d0

View File

@ -854,17 +854,12 @@ git checkout main
# 2. Publier sur chaque instance (corps = CHANGELOG + les 2 APK attachés) # 2. Publier sur chaque instance (corps = CHANGELOG + les 2 APK attachés)
# ⚠️ NE JAMAIS comparer les tags en chaînes (v1.2.10 < v1.2.5 # ⚠️ NE JAMAIS comparer les tags en chaînes (v1.2.10 < v1.2.5
# lexicographiquement !) — comparer en tuples numériques (§14 #38) # lexicographiquement !) — comparer en tuples numériques (§14 #38)
# ⚠️⚠️ CONFIRMÉ v1.2.10 + v1.3.0 + v1.3.1 : les DEUX invocations # ⚠️ NE JAMAIS utiliser gitea-release.py en deux invocations rapprochées
# remplacent mutuellement (le 2e upload écrase le 1er, nom générique) — # (les uploads se remplacent mutuellement, confirmé 4 fois) :
# BUG RÉCURRENT, confirmé 3 fois. Pattern OBLIGATOIRE : UNE passe Python inline — # → UNE invocation de **scripts/publish-release.py** par instance fait
# purge des assets, upload séquentiel, VÉRIFICATION PAR TÉLÉCHARGEMENT # tout (purge + upload des 2 APK + vérification par téléchargement).
# de CHAQUE asset puis RE-VÉRIFICATION FINALE des deux (listing ET python3 scripts/publish-release.py cloudyfy vX.Y.Z
# contenu délivré). Le script one-shot par APK ne suffit plus. python3 scripts/publish-release.py farewell vX.Y.Z
# Pattern validé : UNE passe Python par instance — purge des assets,
# upload séquentiel des 2 APK, vérification par TÉLÉCHARGEMENT de chaque
# asset puis re-vérification finale des deux (le listing peut mentir).
# Cf la séquence inline utilisée et validée en v1.2.6/v1.2.10/v1.3.0/v1.3.1
# (dans l'historique de session de ce dépôt).
``` ```
Le script choisit l'instance (URL, owner) et lit le token Gitea correspondant Le script choisit l'instance (URL, owner) et lit le token Gitea correspondant
@ -923,9 +918,11 @@ vérifie pas en tests JVM).
`app-release.apk` → `/tmp/apks/HormoneTrack-vX.Y.Z-release.apk` et `app-release.apk` → `/tmp/apks/HormoneTrack-vX.Y.Z-release.apk` et
`app-debug.apk` → `HormoneTrack-vX.Y.Z-debug.apk` → `git checkout main`. `app-debug.apk` → `HormoneTrack-vX.Y.Z-debug.apk` → `git checkout main`.
7. **Publier les releases** (corps = section CHANGELOG + les 2 APK attachés) : 7. **Publier les releases** (corps = section CHANGELOG + les 2 APK attachés) :
`python3 scripts/gitea-release.py cloudyfy vX.Y.Z <release.apk>` puis `python3 scripts/publish-release.py cloudyfy vX.Y.Z` puis idem avec
idem avec `<debug.apk>` ; répéter avec l'instance `farewell` (token `farewell` (⚠️ UNE invocation = les 2 APK + vérification par
`gitea.farewell.dev` requis dans le trousseau, absent à ce jour). téléchargement — NE PAS utiliser gitea-release.py deux fois de suite,
les uploads rapprochés se remplacent mutuellement, cf §14 #43 ;
token `gitea.farewell.dev` requis dans le trousseau).
8. **Smoke-test R8 sur téléphone** (le release APK n'est pas vérifiable en 8. **Smoke-test R8 sur téléphone** (le release APK n'est pas vérifiable en
tests JVM) : installation par-dessus l'existant, graphiques, export ET tests JVM) : installation par-dessus l'existant, graphiques, export ET
import d'un backup JSON, rappel. Le debug APK est le repli (même signature). import d'un backup JSON, rappel. Le debug APK est le repli (même signature).