| … | … | @@ -120,6 +120,56 @@ steps: |
| 120 | 120 | ls -l favela-android.apk worklet.bundle tree.json apk.tree.json |
| 121 | 121 | timeout: 2700 |
| 122 | 122 | |
| 123 | # ── the worklet bundle, into the RELEASE REGISTRY, so a phone can fetch it P2P ───────────────── |
| 124 | # |
| 125 | # The `artifacts:` block below publishes files the forge serves over HTTPS at |
| 126 | # /git/releases/<repo>/<version>/<file>. That is how the phone has always updated, and it is the |
| 127 | # problem: 7rnx.net/git is LOAD-BALANCED, a release lands on the backend that built it and replicates |
| 128 | # to the other asynchronously, and the phone asks whichever answers. Measured 2026-08-25 — 0.1.6 |
| 129 | # replicated in ~15s, 0.1.7 had NOT replicated after 600s and the phone correctly reported no update. |
| 130 | # Measured before that on 2026-08-18, a 153 MB APK never reached the second backend at all. |
| 131 | # |
| 132 | # `pgh publish` is the other half, and the one every other hyper-fleeky app already uses: it |
| 133 | # content-addresses the tree into the ReleaseRegistry, which a standalone device replicates over |
| 134 | # HYPERSWARM by the publisher's registry key — no sidecar, no HTTPS, no backend to be on the wrong side |
| 135 | # of. Proven end-to-end from a sidecar-free process before this step was written: resolve 13.1s cold, |
| 136 | # getTree 6ms, getContent 19ms (pgh/lib/resolve-release.js path 2 + NetworkFetcher). |
| 137 | # |
| 138 | # ⛔ THE BUNDLE ONLY, NOT THE APK. The APK is 154 MB per build and the content store keeps every one; |
| 139 | # `releases` was already 6.74 GiB with nothing scheduling gc (hyper-social #47 §2). Fetching the APK |
| 140 | # P2P needs PackageInstaller + REQUEST_INSTALL_PACKAGES anyway (#54 §8) — apk.tree.json is published |
| 141 | # for that and nothing consumes it yet, so putting 154 MB into the store now would buy nothing. |
| 142 | # |
| 143 | # ⛔ THIS TREE HAS TWO ENTRIES (package.json + worklet.bundle), because pgh publish requires a manifest. |
| 144 | # The bundle must therefore be selected BY NAME on the phone, never by position — see the note in the |
| 145 | # assemble step above about materialize keeping the LAST file entry, which is exactly the trap that |
| 146 | # would otherwise stage a manifest as the worklet bundle. |
| 147 | - name: pgh publish (worklet bundle → release registry, for P2P OTA) |
| 148 | run: | |
| 149 | set -e |
| 150 | rm -rf .pgh-publish && mkdir -p .pgh-publish |
| 151 | cp worklet.bundle .pgh-publish/worklet.bundle |
| 152 | # Version comes from the repo's package.json — the same field pgh publish reads for every other |
| 153 | # app, so a release is identified the way the rest of the fleet identifies one. |
| 154 | VERSION=$(node -p "require('./package.json').version") |
| 155 | cat > .pgh-publish/package.json <<JSON |
| 156 | { |
| 157 | "name": "favela-android", |
| 158 | "version": "$VERSION", |
| 159 | "pgh": { |
| 160 | "upgrade": "pgh://1dd36bdfa9cb7f7d84adbd07f017e7200f7f90a3a546cd0761fac2a1f8a13e86/favela-android", |
| 161 | "runtime": "bare" |
| 162 | } |
| 163 | } |
| 164 | JSON |
| 165 | cat .pgh-publish/package.json |
| 166 | # --accept-conflict: republishing one version with different content is EXPECTED here, because a |
| 167 | # branch rebuild re-runs without a version bump. Same reason hyper-proto-peer's publish carries it. |
| 168 | pgh publish .pgh-publish --accept-conflict "automated CI publish of the favela-android worklet bundle; version tracks package.json and a branch rebuild republishes it" |
| 169 | # Prove the registry actually has it, in the build log, rather than assuming the publish landed. |
| 170 | pgh releases latest favela-android || true |
| 171 | timeout: 300 |
| 172 | |
| 123 | 173 | artifacts: |
| 124 | 174 | # ⛔ FILES ONLY — collectArtifacts uses readFile, with no directory walk and no globbing. |
| 125 | 175 | - favela-android.apk |