Magnus Jensen
cfcca6a6ac
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #45441 The issue is when hitting the `svc.DeleteMDMAppleBootstrapPackage` via the API/UI, it only clears the row in `mdm_apple_bootstrap_packages`. However when GitOps runs the next time, it compares the old team config, which has a stale `macos_setup.bootstrap_package` config value. Which forces it to call the same Delete method again. This PR adds the defensive approach to gracefully handle a not found bootstrap package when GitOps wants to delete it. The reason the second run works, is that we only attempt to delete the bootstrap package after we called SaveTeam with the new empty `bootstrap_package` value. So next run sees it as empty and avoid calling the Delete method. _One question is if we want to add a more active approach on the delete service method, which also handles updating the team config clearing out this value? That would have prevented the cause, I think either keeping only this layer, or doing both solutions is a good approach._ # 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), 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 - [x] If paths of existing endpoints are modified without backwards compatibility, checked the frontend/CLI for any necessary changes ## Testing - [x] Added/updated automated tests - [x] QA'd all new/changed functionality manually <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * GitOps automation no longer fails on its first run after a bootstrap package is deleted via the UI. * Clearing a macOS bootstrap package (team or app config) now succeeds even if the underlying package record is already missing. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
Platform packages
This directory contains infrastructure and cross-cutting technical concerns that are independent of Fleet's business domain. These packages provide foundational capabilities used across the codebase.
Platform vs domain
Following separation of concerns, we distinguish:
- Platform (infrastructure): Technical concerns like database connectivity, HTTP utilities, middleware, and transport-level error handling. These packages have no knowledge of Fleet's business domain.
- Domain (business logic): Feature-specific code organized into bounded contexts. Domain packages depend on platform packages, not the reverse.
Guidelines
- Platform packages must not import domain packages
- Platform packages should be general-purpose and reusable
- Architectural boundaries are enforced by
arch_test.go