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).
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).
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).
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>
New workflow .github/workflows/triage-user-issues.yml. On issues:opened, if
the author is external (author_association not OWNER/MEMBER/COLLABORATOR),
apply user-submitted + priority:P2 + board:backlog using PROJECT_PAT so the
existing sync-labels-to-board.yml fires and sets Status=Backlog /
Priority=Medium on board #2. Maintainer-opened issues are untouched. type:
is left for manual triage.
workflow_dispatch entrypoint added for manual re-triage and the post-merge
live test: both triggers require the workflow to be on the default branch
first (issues:-triggered workflows only run from default; a new
workflow_dispatch is only dispatchable once on default), so validation
happens after the merge to dev.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
deploy.yml (inherited from upstream zjs81) fired on every tag push and failed on a missing CLOUDFLARE_API_TOKEN — secrets do not fork. Switch to workflow_dispatch-only to stop the per-tag failures; preserve the job for the scoped Offband web-app launch (Feature #121 / Epic #122).
The OffbandMesh org board (project #2) had no label->board sync, so issues never populated it (root cause of the 0-item board). Add sync-labels-to-board.yml (adapted from the DifferentWire/Unfocused canonical) wired to board #2's project + status/priority field and option IDs; runs on ubuntu-latest, uses repo secret PROJECT_PAT (classic PAT, project+repo scope). REQUIRES PROJECT_PAT set as a repo secret to function.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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.