mirror of
https://github.com/fleetdm/fleet
synced 2026-05-24 09:28:54 +00:00
61970118e9
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #33173 **Related issue:** Resolves #33111 # Details This is the remaining work to implement the "Stop the setup experience when required software fails to install" feature. This didn't turn out to be quite as straightforward as expected so I ended up doing a bit of design-by-code and expect some feedback on the approach. I tried to make it as low-touch as possible. The general design is: 1. In the `maybeUpdateSetupExperienceStatus` function which is called in various places when a setup experience step is marked as completed, call a new `maybeCancelPendingSetupExperienceSteps` function if the setup step was marked as failed. Similarly call `maybeCancelPendingSetupExperienceSteps` if a VPP app install fails to enqueue. 2. In `maybeCancelPendingSetupExperienceSteps`, check whether the specified host is MacOS and whether the "RequireAllSoftwareMacOS" flag is set in the team (or global) config. If so, mark the remaining setup experience items as canceled and cancel any upcoming activities related to those steps. 3. On the front-end, if the `require_all_software_macos` is set and a software step is marked as failed, show a new failure page indicating that setup has failed and showing details of the failed software. 4. On the agent side, when checking setup experience status, send a `reset_after_failure` flag _only the first time_. If this flag is set, then the code in the `/orbit/setup_experience/status` handler will clear and re-queue any failed setup experience steps (but leave successful steps to avoid re-installing already-installed software). This facilitates re-starting the setup experience when the host is rebooted. I also updated the way that software (packages and VPP) is queued up for the setup experience to be ordered alphabetically, to make it easier to test _and_ because this is a desired outcome for a future story. Since the order is not deterministic now, this update shouldn't cause any problems (aside from a couple of test updates), but I'm ok taking it out if desired. # 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. - [X] Input data is properly validated, `SELECT *` is avoided, SQL injection is prevented (using placeholders for values in statements) ## Testing - [X] Added/updated automated tests * Added a new integration test for software packages, testing that a failed software package causes the rest of the setup experience to be marked as failed when `require_all_software_macos` is set, and testing that the "reset after failure" code works. * Added a new integration test for VPP packages, testing that a failed VPP enqueue causes the same halting of the setup experience. I _don't_ have test for a failure _during_ a VPP install. It should go through the same code path as the software package failure, so it's not a huge gap. - [ ] QA'd all new/changed functionality manually Working on it ## 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 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - New Features - Configurable option to halt macOS device setup if any software install fails. - Device setup page now shows a clear “Device setup failed” state with expandable error details when all software is required on macOS. - Improvements - Setup status now includes per-step error messages for better troubleshooting. - Pending setup steps are automatically canceled after a failure when applicable, with support to reset and retry the setup flow as configured. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Ian Littman <iansltx@gmail.com> |
||
|---|---|---|
| .. | ||
| activityMock.ts | ||
| appleMdm.ts | ||
| axiosError.ts | ||
| certificatesMock.ts | ||
| commonMock.ts | ||
| configMock.ts | ||
| deviceUserMock.ts | ||
| fileMock.js | ||
| hostMock.ts | ||
| idpMock.ts | ||
| labelsMock.ts | ||
| licenseMock.ts | ||
| macAdminsMock.ts | ||
| mdmMock.ts | ||
| operatingSystemsMock.ts | ||
| osqueryTableMock.ts | ||
| policyMock.ts | ||
| queryMock.ts | ||
| queryReportMock.ts | ||
| README.md | ||
| scheduleableQueryMock.ts | ||
| scriptMock.ts | ||
| setupExperienceMock.ts | ||
| softwareMock.ts | ||
| teamMock.ts | ||
| userMock.ts | ||
| vulnerabilitiesMock.ts | ||
Frontend mocks
Each __mocks___/*Mock.ts file contains one or more default mock objects and their corresponding helper function to partially override the default mock creating custom mocks.
Table of contents
- Default mocks usage -Example
- Custom mocks usage -Global handlers vs. inline handlers -Examples
- Related links
Default mocks
Default mocks are simple to work with objects. We limit the default mock to a single object that can be modified with the helper function as needed using overrides.
The default mock object is returned by calling the helper function with no arguments.
Example
A single default activity is defined in __mocks__/activityMock.ts as:
const DEFAULT_ACTIVITY_MOCK: IActivity = {
created_at: "2022-11-03T17:22:14Z",
id: 1,
actor_full_name: "Test",
actor_id: 1,
actor_gravatar: "",
actor_email: "test@example.com",
type: ActivityType.EditedAgentOptions,
};
To return this default object, call its helper function createActivityMock() with no arguments.
Custom mocks
Custom mocks are useful when we need a mock object with specific data.
Use the helper function with arguments to override the default mock data with the specific data you need.
Example
createMockActivity({ id: 2, actor_full_name: "Gabe" }) will return modifications to the DEFAULT_ACTIVITY_MOCK to override the id and actor_full_name keys only.
Related links
Check out the frontend test directory for information about our unit and integration testing layers. We use default mocks and custom mocks when mocking server requests.
Follow this guide to run tests locally.
Visit the frontend overview of Fleet UI testing for more information on our testing strategy, philosophies, and tools.