admin-mrrm/mrrmlabapp

Fork 0

chore(ci): .drone.yml gitea-release — ${APK} wird von Drone-YAML zu leerem String interpoliert #411

New issue

Closed

opened 2026-05-27 21:58:54 +02:00 by pm-bot · 1 comment

pm-bot commented

2026-05-27 21:58:54 +02:00

Collaborator

Problem

In .drone.yml:490 (gitea-release-Step der publish-apk-Pipeline):

-F "attachment=@${APK}" \

Drone substituiert ${VAR}-Syntax beim YAML-Parsen vor der Shell-Ausführung. APK ist kein Drone-Built-in, also wird ${APK} zu Leerstring. Im Drone-Log von Build #871 sichtbar als:

-F "attachment=@" \

Obwohl direkt darüber echo "APK: $APK" korrekt den Pfad ausgibt ($APK ohne Klammern wird von Drone nicht angefasst).

Symptom

Tag-Build #871 (v0.4.6) ist im gitea-release-Step mit curl: (26) Failed to open/read local data from file/application gestorben. Gitea-Release v0.4.6 wurde erstellt, aber ohne APK-Asset. F-Droid-Scraper und Download-Link auf der Release-Page finden nichts.

Fix

.drone.yml:490: ${APK} → $APK (oder $${APK} als Drone-Escape).

-          -F "attachment=@${APK}" \
+          -F "attachment=@$APK" \

Konsistent mit den anderen Variablen-Referenzen im selben Block (alle nutzen $VAR ohne Klammern).

Wer betroffen

Jeder Tag-Cut ab v0.4.6 würde dasselbe Problem zeigen, solange der Bug drin ist. v0.4.5 funktionierte zufällig — das war derselbe Block, aber mit anderem $VAR-Stil (siehe Commit-History von .drone.yml, Issue #406/PR #407).

Stopgap

Für v0.4.6 wird die APK manuell aus /opt/server-stack/hosts/prod-alt/mrrmlabapp/fdroid/repo/ auf das bestehende Release hochgeladen — kein Re-Tag.

Akzeptanzkriterien

.drone.yml:490 gefixt
Nächster Tag-Cut lädt APK erfolgreich als Release-Asset
Optional: Smoke-Schritt vor curl -F der test -s "$APK" macht, damit der Fehler nicht erst auf curl-Ebene knallt

## Problem In `.drone.yml:490` (gitea-release-Step der publish-apk-Pipeline): ```yaml -F "attachment=@${APK}" \ ``` Drone substituiert `${VAR}`-Syntax beim YAML-Parsen *vor* der Shell-Ausführung. `APK` ist kein Drone-Built-in, also wird `${APK}` zu Leerstring. Im Drone-Log von Build #871 sichtbar als: ``` -F "attachment=@" \ ``` Obwohl direkt darüber `echo "APK: $APK"` korrekt den Pfad ausgibt (`$APK` ohne Klammern wird von Drone nicht angefasst). ## Symptom Tag-Build #871 (v0.4.6) ist im `gitea-release`-Step mit `curl: (26) Failed to open/read local data from file/application` gestorben. Gitea-Release `v0.4.6` wurde erstellt, aber **ohne APK-Asset**. F-Droid-Scraper und Download-Link auf der Release-Page finden nichts. ## Fix `.drone.yml:490`: `${APK}` → `$APK` (oder `$${APK}` als Drone-Escape). ```diff - -F "attachment=@${APK}" \ + -F "attachment=@$APK" \ ``` Konsistent mit den anderen Variablen-Referenzen im selben Block (alle nutzen `$VAR` ohne Klammern). ## Wer betroffen Jeder Tag-Cut ab v0.4.6 würde dasselbe Problem zeigen, solange der Bug drin ist. v0.4.5 funktionierte zufällig — das war derselbe Block, aber mit anderem `$VAR`-Stil (siehe Commit-History von `.drone.yml`, Issue #406/PR #407). ## Stopgap Für v0.4.6 wird die APK manuell aus `/opt/server-stack/hosts/prod-alt/mrrmlabapp/fdroid/repo/` auf das bestehende Release hochgeladen — kein Re-Tag. ## Akzeptanzkriterien - [ ] `.drone.yml:490` gefixt - [ ] Nächster Tag-Cut lädt APK erfolgreich als Release-Asset - [ ] Optional: Smoke-Schritt vor `curl -F` der `test -s "$APK"` macht, damit der Fehler nicht erst auf curl-Ebene knallt

pm-bot added the

type/chore

area/infra

labels

2026-05-27 21:58:54 +02:00

admin-mrrm referenced this issue from a commit

2026-05-27 22:35:33 +02:00

chore(roadmap): v0.4.6 → done

pm-bot referenced this issue

2026-05-27 22:43:32 +02:00

Portfolio-Status KW 2026-W22 #412

pm-bot referenced this issue

2026-05-27 22:48:21 +02:00

Portfolio-Status KW 2026-W22 #412

pm-bot commented

2026-05-27 22:48:21 +02:00

Author

Collaborator

GF-Entscheidung: Kein eigener Patch-Release

Per #412 (KW 2026-W22, Punkt b) wird dieser CI-Bug nicht als eigener v0.4.7-Patch ausgeliefert, sondern beim nächsten regulären Feature-Tag-Cut mitgenommen.

Begründung: Kein User-Impact (v0.4.6 ist via Stopgap-APK-Upload vollständig). Patch-Release nur für Engineering-Hygiene erzeugt Cut-Lärm.

Konsequenz: Bis zum nächsten Tag-Cut bleibt für jeden Release der manuelle APK-Upload-Stopgap nötig. Fix selbst ist ein 1-Zeiler (${APK} → $APK), kann jederzeit gemerged werden — ohne separates Release.

## GF-Entscheidung: Kein eigener Patch-Release Per #412 (KW 2026-W22, Punkt b) wird dieser CI-Bug **nicht** als eigener v0.4.7-Patch ausgeliefert, sondern beim nächsten regulären Feature-Tag-Cut mitgenommen. **Begründung:** Kein User-Impact (v0.4.6 ist via Stopgap-APK-Upload vollständig). Patch-Release nur für Engineering-Hygiene erzeugt Cut-Lärm. **Konsequenz:** Bis zum nächsten Tag-Cut bleibt für jeden Release der manuelle APK-Upload-Stopgap nötig. Fix selbst ist ein 1-Zeiler (`${APK}` → `$APK`), kann jederzeit gemerged werden — ohne separates Release.

admin-mrrm referenced this issue from a commit

2026-05-28 09:20:34 +02:00

fix(ci): Drone-YAML-Interpolation in gitea-release-Asset-Upload

pm-bot referenced this issue from a pull request that will close it,

2026-05-28 09:20:47 +02:00

fix(ci): Drone-YAML-Interpolation in gitea-release-Asset-Upload (#411) #417

admin-mrrm closed this issue

2026-05-28 12:52:21 +02:00

admin-mrrm referenced this issue from a commit

2026-05-28 12:52:23 +02:00

Merge pull request 'fix(ci): Drone-YAML-Interpolation in gitea-release-Asset-Upload (#411)' (#417) from fix/411-drone-apk-interpolation into main