main
dev
chore/365-cut-1.2.1
fix/363-pin-db-path
feat/351-contact-settings-menu
feat/349-window-geometry
feat/355-migration-merge
integration/290-306-335
release/1.1.2-rc.3-allplatforms
fix/309-path-len-decode
chore/298-path-logging
fix/285-ingest-timelog
fix/252-block-outgoing-dm
feat/64-observer-config
feat/batch1-ux
chore/offband-rebrand
v1.2.1
v1.2.0
v1.1.2-rc.3-allplatforms
v1.1.2-rc.3
v1.1.2-rc.2
v1.0.0
observer-g2-rc3
observer-g2-rc4
observer-g2-rc5
observer-g2-rc6
observer-g2-rc7
observer-g2-rc8
observer-g2-rc9
v1.1.0-rc.1
v1.1.0-rc.2
v1.1.0-rc.3
v1.1.2-beta.1
v1.1.2-beta.2
v1.1.2-beta.3
v1.1.2-ble-test
v1.1.2-queuediag
v1.1.2-rc.1
v1.1.2-rc.1-b45-nearbyrep
v1.1.2-rc.1-b46-pathhash
v1.1.2-rc.1-b47-tracewidth
v1.1.2-rc.1-b48-repeatertrace
v1.1.2-rc.1-b49-maptrace
v1.1.2-rc.1-b50-tracefix
v1.1.2-rc.1-b51-originstrip
v1.1.2-rc.1-b52-channelqr
v1.1.2-rc.1-b53-viarepeater
v1.1.2-rc.1-b54-rxfed
v1.1.2-rc.1-b55-topology
v1.1.2-rc.1-b57-routeux
v1.1.2-rc.1-b58-toporeadout
v1.1.2-rc.3-b59-pathlen
${ item.name }
${ noResults }
2 Commits (feat/351-contact-settings-menu)
| Author | SHA1 | Message | Date |
|---|---|---|---|
|
|
83c965ef44 |
feat(#339): deploy web client to offband.app via Cloudflare Pages
Publishes the Flutter web client. offband.org stays the Hugo marketing site in OffbandMesh/offband-site, a separate Pages project, untouched. push to main -> --branch=main -> production -> offband.app push to dev -> --branch=dev -> dev tier -> dev.offband.app Direct upload only. Cloudflare's dashboard "Connect to Git" must not be enabled for this project; it would create a second git-integrated project racing this workflow. Matches how offband-site deploys. Because direct-upload projects cannot configure production branch controls in the Cloudflare dashboard, the "never auto-deploy arbitrary branches to prod" requirement from #122 is enforced by the workflow's trigger list instead. That is the safety mechanism, and it is better placed here than in dashboard state: reviewable and version controlled. Builds via build_pipe rather than a plain `flutter build web`, because build_pipe appends ?v=<version> to the bootstrap and manifest files. Without it, browsers serve stale bundles after a deploy. Two fixes folded in: - pubspec.yaml build_pipe build_command did not pass --dart-define-from-file, so a deployed site would have shipped a dead GIF picker even though #331 wired the key into build.yml. The deploy path and the CI path used different build commands. - Retired the inherited zjs81 Workers deploy: removed deploy.yml and wrangler.toml (which targeted THEIR account's "meshcore" project) and dropped the now-dead `deploy` script from package.json. A root wrangler.toml carrying Workers config can also interfere with `wrangler pages deploy`. Verified locally by running the real build with the bench toolchain: build_pipe accepts the new flag, cache busting is applied (flutter_bootstrap.js?v=e2019703...), output is 46 files with a 10.2 MB largest asset (Pages limits are 25 MiB per asset and 20000 files), and the Giphy key is confirmed compiled into main.dart.js. Not verifiable locally: whether the repo's CLOUDFLARE_API_TOKEN carries Pages:Edit scope. The workstation token is DNS-only and 403s on the Pages API. A 403 on first deploy would indicate wrong scope; it fails safely. Part of epic #312, plan #321 (Phase 4). |
1 day ago |
|
|
40ac95e8e6 |
wrangler deploy
|
5 months ago |