meshcore-client

Commit Graph

Author	SHA1	Message	Date
Strycher	f6ed3613eb	fix(#445 ): bundle native-assets DLLs (sqlite3, llamadart) into desktop builds Clean Windows builds (incl. CI) shipped no sqlite3.dll, so drift could not open its database ("Message storage unavailable"), and the llamadart translation libs were stranded too. Root cause: the project moved to sqlite3 v3.x, which delivers its native lib via Dart native assets, but (a) native assets was not enabled in CI and (b) the stock windows/CMakeLists.txt guards the native-assets install with a configure-time `if(EXISTS)` that is false on a clean build (native assets are built AFTER cmake configures), so the install was silently skipped. Dev machines only worked via leftover DLLs from prior builds. Fixes: - windows/CMakeLists.txt: defer the native-assets copy to install time (matches Linux's unconditional install), so a clean build bundles build/native_assets/ windows/*.dll into the runner Release dir. - build.yml + release-signed.yml: enable native assets (flutter config --enable-native-assets) in the windows/linux/macos jobs before build. Verified on a clean local Windows build: Release now contains sqlite3.dll plus the llama/ggml/mtmd set. Android (Gradle-delivered .so) and web (wasm) unchanged. Citadel: meshcore-open-mkl	2 months ago
Strycher	b7584bd0c2	chore(#352 ): generate drift code in CI instead of committing it Replaces the stopgap (`53f87f5`) that committed lib/storage/drift/offband_database.g.dart to green CI. Restores the repo's "generated files are not committed" convention: - dropped the .gitignore negation; the .g.dart is gitignored + untracked (git rm --cached, working copy kept) - added `dart run build_runner build --delete-conflicting-outputs` immediately after `flutter pub get` in every Dart job: flutter_dart (analyze), build.yml (all 6), release-signed (android-signed), deploy-web (before build_pipe) - keeps the drift_dev 2.34.0 / drift 2.34.2 / build_runner ^2.15.1 pins from the stopgap for deterministic generation Verified locally on the bench toolchain (3.44.1): deleted the working .g.dart, ran build_runner from scratch (regenerated cleanly), confirmed the generated file passes `dart format --set-exit-if-changed` and full `flutter analyze --fatal-infos --fatal-warnings` is clean with the file generated (not tracked). For #335 / PR #348. Agent: SapphireCompass (session 8d755b5e)	2 months ago
Strycher	e17f539d7e	chore(#331 ): pass GIPHY_API_KEY into artifact builds Owner added GIPHY_API_KEY as a repo secret, resolving the open decision flagged on this issue. The app reads the key at COMPILE time via String.fromEnvironment('GIPHY_API_KEY') (lib/widgets/gif_picker.dart:25), so CI builds produced without it ship a non-functional GIF picker that displays a "needs a Giphy API key" hint. That was harmless while CI output was discarded; it stopped being harmless in #322 when artifacts became real deliverables. Generates dart_defines.json from the secret and passes --dart-define-from-file, matching how the project is built locally rather than inventing a second mechanism. Wired into the four jobs that produce artifacts users run: android, linux, web, windows. NOT wired into ios and macos, which are compile checks producing nothing installable, and where the key would have no effect on whether compilation succeeds. Uses jq on the Linux runners rather than hand-escaped printf, so the value is JSON-escaped correctly whatever it contains. An earlier printf attempt silently mangled an escape and broke the YAML, which is the argument for using the tool instead of string juggling. jq is verified preinstalled on the runner images (Ubuntu 22.04 has 1.6, 24.04 has 1.7.1). The windows runner uses PowerShell ConvertTo-Json, since jq is not guaranteed there. Note: the key is compiled into the binary and is therefore extractable from any published APK. Putting it in CI does not widen exposure beyond what shipping the app already does. Part of epic #312, plan #321 (Phase 3).	2 months ago
Strycher	1d6558ef8a	chore(#331 ): pin Flutter to 3.44.1 in every workflow Three different Flutter versions were in play and none was the bench: build.yml channel: stable (floating, resolving to 3.44.6) flutter_dart.yml channel: stable (floating) deploy.yml pinned 3.41.2, with a comment claiming it matched local development, which had not been true for months bench 3.44.1 / Dart 3.12.1 A floating toolchain is tolerable for a compile check and not tolerable once CI produces signed release artifacts (#330), so this lands first. Pinned all 8 flutter-action usages to 3.44.1, matching the bench exactly, so "works locally" and "works in CI" mean the same thing. Verified against Flutter's release index that 3.44.1 is a published stable release (2026-06-01, Dart 3.12.1) rather than assuming a locally-installed version was publicly fetchable. Corrected deploy.yml's misleading local-parity comment rather than leaving it to mislead the next reader. Note: CI's green history is on 3.44.6 or later, so pinning DOWN may surface a break the newer toolchain masked. That is the intent. If it breaks, fix the break or move the bench up deliberately; do not re-float the pin. GIPHY_API_KEY as a CI secret was the third item of Phase 3 in #321. It is deliberately NOT included here, is not dropped, and is flagged on #331 for the owner's decision, since it is a credential only they can create. Part of epic #312, plan #321 (Phase 3).	2 months ago
Strycher	2ff190cee1	fix(#322 ): use PR head SHA in artifact names, not the merge SHA Gemini adversarial review caught a real traceability defect. On a `pull_request` event, `github.sha` evaluates to the last merge commit of `refs/pull/N/merge`, not the PR head commit. That merge commit is ephemeral and is not present in branch history, so a PR artifact named with it cannot be traced back to any real commit, which defeats the acceptance criterion this change was written to satisfy. Verified against GitHub's events-that-trigger-workflows reference: "Note that GITHUB_SHA for this event is the last merge commit of the pull request merge branch." Now uses `github.event.pull_request.head.sha \|\| github.sha`, which resolves to the PR head on pull_request events and falls back to the push SHA on pushes to dev/main. Part of epic #312, plan #321 (Phase 1).	2 months ago
Strycher	8ea5ede1dc	chore(#322 ): upload build artifacts + build on dev pushes Two diagnostics faults from #313, fixed together: 1. Dead push trigger. build.yml and flutter_dart.yml declared `push: branches: [main]`, but no `main` branch exists in this repo (default is `dev`), so the push half of every trigger had never fired. Nothing built on merge. Added `dev` to both; `main` is created separately after this merges. 2. No artifacts. All six platform jobs stopped at `flutter build`, so every binary CI produced was discarded with the runner. Added actions/upload-artifact to the four jobs that produce something installable or servable: android build/app/outputs/flutter-apk/app-release.apk windows build/windows/x64/runner/Release/ linux build/linux/x64/release/bundle/ web build/web/ ios and macos are compile checks only and upload nothing: ios is built --no-codesign so it is not installable, and macos is kept as a compile check per the owner's decision on #321. Artifacts carry run number + commit SHA so a build traces back to a commit, and use if-no-files-found: error so a wrong path fails loudly rather than silently publishing an empty artifact. Android artifacts are debug-signed for now; real signing is Phase 5. The web artifact is the plain `flutter build web` output, not the build_pipe versioned build used for deploys; Phase 4 addresses that. Part of epic #312, plan #321 (Phase 1, owner-approved).	2 months ago
Strycher	39274488c3	ci(#227 ): add windows build job to build.yml CI never compiled Windows, the primary test bench (RAK4631 / COM12 / USB serial). Add a windows job mirroring the existing platform jobs: runs-on windows-latest, flutter-action stable, pub get, flutter build windows --release --no-pub. Advisory to start (not in branch-protection required checks); flip to required after 5 green runs (#226). The first run validates the windows-latest env against the local bench (C++ ATL, Developer Mode, llamadart/vulkan, flserial); fixes applied per the #226 plan. Part of #226. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	3 months ago
446564	6070802213	stop building twice for pull requests we should only run the build steps on a pull request OR a push to main	8 months ago
Michael Lynch	1726119c3e	Add a Github Action to build code in CI This adds a CI workflow in Github Actions to verify that the flutter builds compile for all supported platforms. I tried adding Windows, but it currently fails, so I excluded it from this initial set.	8 months ago

9 Commits (f6ed3613ebcfbb31f9006e19e80e3d8651da1ccc)