mirror of
https://github.com/fleetdm/fleet
synced 2026-05-06 06:48:54 +00:00
a187842260
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #38322 This PR utilizes the ping/status ticker that sees if the device is Unmanaged (aka. not enrolled from a Fleet server perspective), if the Migrate to Fleet flow before had set the `mdm_migration.txt` file, but somehow not successfully unenrolled the device, we now keep sending it if you trigger the modal again. We wait 90seconds after start, so at most the user can go through the flow every 90s, but the server has a hard limit on at most one webhook every 3m, but still it means the user can wait a bit and retry and still see the webhook gets sent now. _PS: Updated the old migration test to go from 1,5m to ~2s execution time with parallel and configurable waitForUnenrollment time (to allow test to set lower values) # Checklist for submitter If some of the following don't apply, delete the relevant line. - [x] Changes file added for user-visible changes in `changes/`, `orbit/changes/` or `ee/fleetd-chrome/changes`. See [Changes files](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/guides/committing-changes.md#changes-files) for more information. ## Testing - [x] Added/updated automated tests - [x] QA'd all new/changed functionality manually ## fleetd/orbit/Fleet Desktop - [x] Verified compatibility with the latest released version of Fleet (see [Must rule](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/workflows/fleetd-development-and-release-strategy.md)) - [x] If the change applies to only one platform, confirmed that `runtime.GOOS` is used as needed to isolate changes - [x] Verified that fleetd runs on macOS, Linux and Windows - [x] Verified auto-update works from the released version of component to the new version (see [tools/tuf/test](../tools/tuf/test/README.md)) --------- Co-authored-by: Jordan Montgomery <elijah.jordan.montgomery@gmail.com> |
||
|---|---|---|
| .. | ||
| adr | ||
| architecture | ||
| assets | ||
| getting-started | ||
| guides | ||
| product-groups | ||
| reference | ||
| research | ||
| responsibilities | ||
| rituals | ||
| workflows | ||
| README.md | ||
Fleet Contributor Documentation
Welcome to the Fleet contributor documentation! This documentation is designed to help you contribute to the Fleet project.
Documentation structure
The documentation is organized into the following sections:
- Getting Started - Setup, building, and testing Fleet
- Guides - How-to guides for common tasks
- Architecture - High-level architecture documentation
- Product Groups - Documentation for specific product groups
- Workflows - Development workflows
- Reference - API reference, configuration, etc.
- ADRs - Architectural Decision Records
- Research - Research documents for product groups
- Responsibilities - Responsibility documents for product groups
Product groups
Fleet is organized into three main product groups:
- MDM - Mobile Device Management
- Orchestration - Device orchestration using osquery
- Software - Software inventory, vulnerability management, and software installation
Contributing
If you're new to Fleet, we recommend starting with the Getting Started section to set up your development environment.
Once you're set up, you can explore the Guides section to learn how to contribute to specific areas of the project.
Architectural Decision Records (ADRs)
We use Architectural Decision Records to document significant architectural decisions. If you're making a significant architectural change, please create an ADR to document your decision.