## Summary
Adds `tools/hangar` — a macOS desktop control panel for working on Fleet
locally: branch management, `fleet serve` orchestration, log tail, dev
MySQL backup/restore, `fleetctl`, GitOps, and `osquery-perf`, all in one
window.
Built with **Go + [Wails 3](https://v3alpha.wails.io)** — the backend is
plain Go (`os/exec`, `syscall`, goroutines) so Fleet engineers can
contribute to it; only the desktop shell is Wails. The `internal/`
packages are pure and unit-tested.
### History note
Hangar started as a Rust/Tauri app. It was ported to Go, and **the Go
port is now the canonical `tools/hangar`**. The original Rust/Tauri
implementation has been removed from the monorepo (preserved in a
standalone repo) — so although this branch's earlier commits add and
then replace the Rust app, the net diff is just the Go app at
`tools/hangar`. The bundle identifier is `com.fleetdm.fleet-hangar`,
matching the original app so existing settings carry over.
# Checklist for submitter
- [x] Input data is properly validated, `SELECT *` is avoided, SQL
injection is prevented (using placeholders for values in statements), JS
inline code is prevented especially for url redirects, and untrusted
data interpolated into shell scripts/commands is validated against shell
metacharacters.
- [x] Timeouts are implemented and retries are limited to avoid infinite
loops
> No `changes/` file: `tools/` is contributor tooling, not a
user-visible Fleet change. No DB migrations, no Fleet config settings,
no fleetd/orbit changes.
## Testing
- [x] Added/updated automated tests (Go unit tests across `internal/`,
including a path-traversal regression for backup deletion)
- [x] QA'd all new/changed functionality manually
## Test plan
- [x] `cd tools/hangar && task dev` launches the app (live-reload)
- [x] `task build` produces `bin/fleet-hangar`; `go test ./...` is green
- [x] First-run gate discovers a local Fleet clone and runs dep checks
- [x] Server tab can run the build chain and start `fleet serve`
- [x] Git tab branch search finds an older branch (e.g. a stale `qa-*`)
by name
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Introduced Fleet Hangar, a comprehensive desktop application for Fleet
development workflows, providing unified controls for server/database
management, git operations, configuration, logging, and troubleshooting.
* Added database backup management with metadata tracking.
* Integrated process orchestration for development services (Docker,
ngrok, Python).
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: George Karr <georgekarrv@users.noreply.github.com>
I saw CodeQL being run on this PR
https://github.com/fleetdm/fleet/pull/47154
But it only modified a .MD file inside the docs/Contributing path, we
also only have MD files in there, so I think it's wasteful to run on
those changes.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Updated CI/CD workflow configuration to optimize pipeline efficiency
by excluding documentation changes from code analysis triggers.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Fixes#40975.
8.0.32 (was running in Aurora managed cloud at the time) -> 8.0.39 (what
we're running now) 8.0.36 -> 8.0.44 (latest 8.0.x version supported by
Aurora; holding off on 8.0.45 until Aurora supports it) 8.4.7 -> 8.4.8
9.5.0 -> 9.6.0
Also bumped the supported Aurora version from 3.07.0 to 3.08.2 to match
what we're running in managed cloud right now
Fleet might work on older patch versions but we'll no longer dev/test on
them. MySQL 9.x not testing previous minor versions matches with our
previous approach for that version.
Since these are all patch/minor bumps (and the overnight build cases are
patch bumps/are covered by AWS envs) automated testing should be
sufficient here.
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Resolves#36052
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Tests**
* Automated failure notifications now include detailed error summaries
* Added code coverage reporting and tracking for Android test suites
* Enhanced test logging and artifact collection for improved visibility
into build issues and failures
<sub>✏️ Tip: You can customize this high-level summary in your review
settings.</sub>
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
This PR adds a new workflow called "Stress Test Go Test" (aka the
RandoKiller) that allows running one or more tests repeatedly up to a
set number of times, or until a test fails. This is useful for:
* Trying to diagnose and debug a flaky test
* Verifying that a proposed fix for a flaky test actually works.
To use:
1. Create a branch whose name ends with "-randokiller"
2. Modify the .github/workflows/config/randokiller.json file to your
specifications (choosing the packages and tests to run, the mysql
matrix, and the number of runs to do)
3. Push up the branch
Since the stress test is intended to run a branch that you'll never
merge, you should feel free to add whatever logs to your tests or code
that will help diagnose failures.
I used this to diagnose and fix
https://github.com/fleetdm/fleet/pull/24697!
