Scott Gress
4e35de2ac3
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #41385 # Details This PR updates `fleetctl` to use the new API urls and params when communicating with Fleet server. This avoids deprecation warnings showing up on the server that users won't be able to fix. Most of the changes are straightforward `team_id` -> `fleet_id`. A couple of code changes have been pointed out. The most interesting is in icon URLs, which can be persisted in the database (so we'll need to do a migration in Fleet 5 if we want to drop support for `team_id`. Similarly the FMA download urls are briefly persisted in the db for the purpose of sending MDM commands. If we drop team_id support in Fleet 5 there could be a brief window where there are unprocessed commands in the db still with `team_id` in them, so we'll probably want to migrate those as well. # Checklist for submitter If some of the following don't apply, delete the relevant line. - [ ] 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. n/a - all internal ## Testing - [X] Added/updated automated tests - [X] QA'd all new/changed functionality manually - [X] ran `fleetctl gitops` on main and saw a bunch of deprecation warnings, ran it on this branch and the warnings were gone 💨 - [X] same with `fleetctl generate-gitops` - [X] ran `fleetctl get` commands and verified that the new URLs and params were used - [X] ran `fleetctl apply` commands and verified that the new URLs and params were used
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