fix(release): corrige release.yml pour Forgejo et y attache un APK signé #72

Merged

kyuno merged 1 commit from fix/release-yml-forgejo into main

2026-09-06 19:15:57 +02:00

kyuno commented

2026-09-06 18:57:59 +02:00

Owner

release.yml datait d'avant la migration vers Forgejo et n'avait jamais été retesté : refs d'action bare (actions/checkout@v4, softprops/action-gh-release@v2) sans le préfixe URL complet qu'exige ce runner self-hosted — même contrainte déjà rencontrée et documentée dans ci.yml.

Ajoute aussi ce que #65/#66 attendaient réellement :

Un job build-android-apk (même recette que ci.yml's build-android, #64) qui construit et signe l'APK, déduit versionName/versionCode du tag poussé (vX.Y.Z → versionName X.Y.Z, versionCode = majeur*10000+mineur*100+correctif) et l'attache à la Release Forgejo sous un nom de fichier stable (batchcooking.apk) via softprops/action-gh-release.
C'est ce nom stable qui permet à /releases/latest/download/batchcooking.apk (page d'accueil, #65) de toujours pointer vers la dernière release sans jamais changer de lien.
build.gradle : versionCode/versionName deviennent surchargeables via -PandroidVersionCode/-PandroidVersionName (défaut inchangé — 1/"1.0" — pour tout build qui ne passe pas ces propriétés, comme le job build-android existant de ci.yml sur un simple push main).

Choix assumé : le job Android est dupliqué depuis ci.yml plutôt que factorisé en workflow_call réutilisable — le support des workflows réutilisables sur ce runner Forgejo/act self-hébergé n'est pas vérifié, et cette recette de ~15 lignes est déjà éprouvée telle quelle. Pas la peine de risquer une nouvelle surprise de compatibilité (ce repo en a déjà croisé plusieurs) pour économiser un peu de duplication.

Non testé de bout en bout dans cette PR : release.yml ne se déclenche que sur un vrai tag poussé (v*.*.*), jamais sur une simple branche/PR — la CI de cette PR ne peut donc exercer que le reste du pipeline (lint/test/build/e2e/intent-service-test), pas release.yml lui-même. Pousser un tag de test ici déclencherait potentiellement un vrai redéploiement Portainer en production si PORTAINER_WEBHOOK_URL est déjà configuré — à tester délibérément avec toi une fois cette PR mergée, pas par un tag improvisé de mon côté.

🤖 Generated with Claude Code

`release.yml` datait d'avant la migration vers Forgejo et n'avait jamais été retesté : refs d'action *bare* (`actions/checkout@v4`, `softprops/action-gh-release@v2`) sans le préfixe URL complet qu'exige ce runner self-hosted — même contrainte déjà rencontrée et documentée dans `ci.yml`. Ajoute aussi ce que #65/#66 attendaient réellement : - Un job `build-android-apk` (même recette que `ci.yml`'s `build-android`, #64) qui construit et signe l'APK, déduit `versionName`/`versionCode` du tag poussé (`vX.Y.Z` → `versionName` `X.Y.Z`, `versionCode` = `majeur*10000+mineur*100+correctif`) et l'attache à la Release Forgejo sous un nom de fichier **stable** (`batchcooking.apk`) via `softprops/action-gh-release`. - C'est ce nom stable qui permet à `/releases/latest/download/batchcooking.apk` (page d'accueil, #65) de toujours pointer vers la dernière release sans jamais changer de lien. - `build.gradle` : `versionCode`/`versionName` deviennent surchargeables via `-PandroidVersionCode`/`-PandroidVersionName` (défaut inchangé — `1`/`"1.0"` — pour tout build qui ne passe pas ces propriétés, comme le job `build-android` existant de `ci.yml` sur un simple push `main`). **Choix assumé** : le job Android est dupliqué depuis `ci.yml` plutôt que factorisé en `workflow_call` réutilisable — le support des workflows réutilisables sur ce runner Forgejo/`act` self-hébergé n'est pas vérifié, et cette recette de ~15 lignes est déjà éprouvée telle quelle. Pas la peine de risquer une nouvelle surprise de compatibilité (ce repo en a déjà croisé plusieurs) pour économiser un peu de duplication. **Non testé de bout en bout dans cette PR** : `release.yml` ne se déclenche que sur un vrai tag poussé (`v*.*.*`), jamais sur une simple branche/PR — la CI de cette PR ne peut donc exercer que le reste du pipeline (`lint`/`test`/`build`/`e2e`/`intent-service-test`), pas `release.yml` lui-même. Pousser un tag de test ici déclencherait potentiellement un vrai redéploiement Portainer en production si `PORTAINER_WEBHOOK_URL` est déjà configuré — à tester délibérément avec toi une fois cette PR mergée, pas par un tag improvisé de mon côté. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

kyuno added 1 commit 2026-09-06 18:58:00 +02:00

fix(release): corrige release.yml pour Forgejo et y attache un APK signe

CI / lint (push) Successful in 2m55s

Details

CI / build (push) Successful in 2m58s

Details

CI / intent-service-test (push) Successful in 4m48s

Details

CI / e2e (push) Successful in 9m34s

Details

CI / test (push) Successful in 17m24s

Details

CI / build-android (push) Has been skipped

Details

854d795c5d

release.yml datait d'avant la migration vers Forgejo et n'avait jamais ete
reteste : refs d'action bares (actions/checkout@v4, softprops/action-gh-
release@v2) sans le prefixe URL complet qu'exige ce runner self-hosted
(meme contrainte deja rencontree et documentee dans ci.yml).

Ajoute aussi ce que #65 attendait reellement : un job build-android-apk
(meme recette que le job build-android de ci.yml, issue #64) qui construit
et signe l'APK, deduit versionName/versionCode du tag pousse (vX.Y.Z ->
versionName X.Y.Z, versionCode majeur*10000+mineur*100+correctif) et
l'attache a la Release Forgejo sous un nom de fichier stable
(batchcooking.apk) via softprops/action-gh-release. C'est ce nom stable qui
permet a /releases/latest/download/batchcooking.apk (page d'accueil, #65)
de toujours pointer vers la derniere release sans jamais changer de lien.

build.gradle : versionCode/versionName deviennent surchargeables via
-PandroidVersionCode/-PandroidVersionName (defaut inchange : 1 / "1.0"
pour tout build qui ne passe pas ces proprietes, comme le job
build-android existant de ci.yml sur un simple push main).

Duplique le job de build Android plutot que de factoriser en workflow_call
reutilisable — le support des workflows reutilisables sur ce runner
Forgejo/act self-hoste n'est pas verifie, et cette recette de ~15 lignes
est deja eprouvee telle quelle dans ci.yml ; pas la peine de risquer une
nouvelle surprise de compatibilite pour economiser un peu de duplication.

Non teste de bout en bout dans cette PR : release.yml ne se declenche que
sur un vrai tag pousse (jamais sur une simple branche/PR), et pousser un
tag ici declencherait potentiellement un vrai redeploiement Portainer en
production si PORTAINER_WEBHOOK_URL est deja configure — a tester
deliberement avec l'utilisateur, pas par un tag de test improvise.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>