Add support for Fleet-maintained app slugs in policies via GitOps

[allenhouchins]

This pull request adds support for referencing Fleet-maintained apps (FMAs) in policy-driven software installation using a new slug field in the install_software section of policy YAML. It updates the GitOps tooling, validation, documentation, and supporting code to enable FMAs to be installed automatically via policies, alongside existing options (custom packages and App Store apps). It also ensures correct validation, mapping, and error handling for the new field.

GitOps and Policy Processing Enhancements:

• Added support for the slug field in the install_software section of policy YAML, allowing policies to trigger installation of Fleet-maintained apps by referencing their slug (e.g., intune-company-portal/darwin). The code ensures only one of package_path, app_store_id, or slug can be specified. [1] [2]
• Updated the GitOps policy generation logic to map slug values to software title IDs using a new FMASlugMap, and to output the correct YAML for FMAs. [1] [2] [3] [4]
• Modified the server-side policy processing to resolve slug values to the correct software title IDs, with proper error handling and logging if the slug is not found or FMAs are not available for the team. [1] [2]
• Introduced a new API client method ListFleetMaintainedApps to retrieve available FMAs for a team. [1] [2]

Validation and Testing:

• Enhanced validation to ensure slug is only used on team policies, cannot be combined with other install options, and is required if no other install fields are set.
• Added and updated tests to cover new validation rules and correct parsing of the slug field in policy specs. [1] [2]
• Updated mocks and test clients to support the new API and prevent nil pointer errors. [1] [2]

Documentation Updates:

• Updated documentation to describe the new slug option in install_software, with examples and instructions for using FMAs in policies. [1] [2] [3] [4]

These changes make it possible to automate the installation of Fleet-maintained apps via policies using a simple and consistent workflow.

Related issue: Resolves #34492

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 for more information.

• Input data is properly validated, SELECT * is avoided, SQL injection is prevented (using placeholders for values in statements)

• If paths of existing endpoints are modified without backwards compatibility, checked the frontend/CLI for any necessary changes

Testing

• Added/updated automated tests

• Where appropriate, automated tests simulate multiple hosts and test for host isolation (updates to one hosts's records do not affect another)

• QA'd all new/changed functionality manually

For unreleased bug fixes in a release candidate, one of:

• Confirmed that the fix is not expected to adversely impact load test results
• Alerted the release DRI if additional load testing is needed

Database migrations

• Checked schema for all modified table for columns that will auto-update timestamps during migration.
• Confirmed that updating the timestamps is acceptable, and will not cause unwanted side effects.
• Ensured the correct collation is explicitly set for character columns (COLLATE utf8mb4_unicode_ci).

New Fleet configuration settings

• Setting(s) is/are explicitly excluded from GitOps

If you didn't check the box above, follow this checklist for GitOps-enabled settings:

• Verified that the setting is exported via fleetctl generate-gitops
• Verified the setting is documented in a separate PR to the GitOps documentation
• Verified that the setting is cleared on the server if it is not supplied in a YAML file (or that it is documented as being optional)
• Verified that any relevant UI is disabled when GitOps mode is enabled

fleetd/orbit/Fleet Desktop

• Verified compatibility with the latest released version of Fleet (see Must rule)
• If the change applies to only one platform, confirmed that runtime.GOOS is used as needed to isolate changes
• Verified that fleetd runs on macOS, Linux and Windows
• Verified auto-update works from the released version of component to the new version (see tools/tuf/test)

[codecov]

Codecov Report

❌ Patch coverage is 35.82090% with 43 lines in your changes missing coverage. Please review.
✅ Project coverage is 65.87%. Comparing base (99d313f) to head (9a342a4).

Files with missing lines	Patch %	Lines
server/service/client.go	13.33%	23 Missing and 3 partials ⚠️
cmd/fleetctl/fleetctl/generate_gitops.go	37.50%	5 Missing and 5 partials ⚠️
server/service/client_software.go	0.00%	7 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #37717      +/-   ##
==========================================
- Coverage   65.88%   65.87%   -0.01%     
==========================================
  Files        2361     2361              
  Lines      187305   187363      +58     
  Branches     8011     8011              
==========================================
+ Hits       123401   123423      +22     
- Misses      52622    52650      +28     
- Partials    11282    11290       +8     

Flag	Coverage Δ
backend	67.72% <35.82%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.