<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Resolves#38785
# Checklist for submitter
## Testing
- [x] QA'd all new/changed functionality manually
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added a manual "force rebuild" option to trigger base MSI/PKG rebuilds
regardless of automatic checks.
* **Chores**
* Improved update detection to more reliably decide when rebuilds are
required by comparing current and new metadata and by validating publish
timestamps.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/fleetdm/fleet/pull/45907?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
I see no reason to use macOS for this job (given how unreliable and slow
macOS runners are).
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* CI workflow runner switched to ubuntu-latest.
* Internal tooling updated to download and prepare the osqueryd binary
for macOS and Linux.
* macOS agent configuration expanded with additional options for
keychain access and file-monitoring behavior.
---
Note: No end-user visible features or breaking changes in this release.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/fleetdm/fleet/pull/45816?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What's the issue I'm trying to solve here?
1. So I have a PR (say branch name `pr-foobar`).
2. The PR will do a docker publish (say docker image with tag
`fleetdm/fleet:pr-foobar`).
3. Load test environment deployed with such docker image tag
(`fleetdm/fleet:pr-foobar`).
4. I go to My account > and see Fleet has version
`0.0.0-SNAPSHOT-<SOME-SHA>` (0.0.0-SNAPSHOT is expected because it's a
branch). Example in screenshot below.
5. I do `git fetch origin && git show <SOME-SHA>` to know exactly what's
deployed.
6. Turns out `<SOME-SHA>` is some SHA known to Github, but not in the
fleet's git repository.
Problem: I really want to tie what's running with an actual commit SHA.
And this PR solves that for these load tests that use branches.
<img width="298" height="809" alt="Screenshot 2026-05-19 at 12 57 05 PM"
src="https://github.com/user-attachments/assets/d46fa037-1de5-4cf0-b768-6ec9dbe33620"
/>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Updated CI/CD workflow checkout behavior so pull-request-triggered
runs use the PR head commit, ensuring the correct code is checked out
and improving build/test reliability and snapshot accuracy.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/fleetdm/fleet/pull/45814?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Resolves#45700
Not a product change. This PR will allow us to run the workflow
manually. After ~2 weeks, if there are no issues, we'll make it
automatic.
## 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
* **New Features**
* Added automated workflow to identify and close stale issues created by
Fleet team members, with dry-run capability and operation limits.
* Added system to build and maintain a deduplicated list of Fleet team
member handles from GitHub organization and repository history.
* **Tests**
* Added comprehensive test suites for stale issue management and handle
list generation with mock GitHub API interactions and boundary condition
coverage.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/fleetdm/fleet/pull/45530?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Resolves#45220 (one of several PRs)
- [x] QA'd all new/changed functionality manually
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Tests**
* Added a dedicated maintained-apps test helper and updated integration
tests to use it, consolidating sync test setup and improving reliability
of maintained-apps scenarios.
* Updated several tests to use improved test utilities and helper
variants for SQL test helpers and request fixtures.
* **Chores**
* Adjusted CI lint checks to exclude the new test helper location from
specific env-var override validations.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/fleetdm/fleet/pull/45494)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Resolves#45497
# 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.
not user-facing
## Testing
- [ ] Added/updated automated tests
- [ ] QA'd all new/changed functionality manually
Kinda hard to test outside of a release, but the sibling .msi upload job
works using the same action SHA.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Updated pinned GitHub Action digests used in CI to newer commits for
improved security and build reliability.
* Reformatted a CI step parameter across multiple YAML lines (no
functional change) to improve readability and maintainability.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/fleetdm/fleet/pull/45498)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Related to, but does not resolve, #45267
Adds a 12h cooldown period such that when npm is resolving dependencies
it will not resolve anything released less than 12 hours ago. This
doesn't apply globally within the fleet project because some portions
use yarn which #45267 will take care of however this does add it to our
CI jobs and the .npmrc files for projects that use npm
I was going to set this as NPM_CONFIG_MIN_RELEASE_AGE in a github EV but
that won't automatically set it on every runner so leaving it in here
for now
As far as QA local builds and CI are both green. Tested
NPM_CONFIG_MIN_RELEASE_AGE=0.5 and min-release-age=0.5(in npmrc) locally
using the npm package feed https://registry.npmjs.org/-/rss to verify
that recently updated packages either chose an older version OR the
update was blocked if I tried to choose a newer one
# Checklist for submitter
## Testing
- [x] QA'd all new/changed functionality manually
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Enhanced npm supply-chain security by implementing package
installation policies across build workflows and configuration files to
exclude packages released within the last 12 hours.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/fleetdm/fleet/pull/45268)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Changes:
- Added a new Github workflow that runs on branches that change the
website's dependencies (website/package-lock.json or
website/package.json), and fails for 72 hours after a change to those
files have been made. After 72 hours, if the workflow has not run again
on a pull request, the workflow can be rerun to give a PR a passing
status.
- Updated the website handbook page to document this process.
@lukeheath After this is merged, I will need help setting up a branch
protection rule to require a passing status from this workflow to merge
pull requests that change the website's dependencies
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Added an automated workflow to enforce a wait period before website
dependency updates can proceed, preventing premature merges.
* Added scheduled and manual re-triggering for recent failed workflow
runs to ensure dependency checks are retried without manual
intervention.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
- Prevents `terraform destroy` from running against load test
infrastructure, for a given workspace, if an identical osquery perf
workspace exists.
- Adds a check to the osquery perf workflow, to fail fast, if the
specified load test infrastructure workspace is not detected.
- Adds ability for users to configure the osquery perf (increment -
`input.loadtest_containers_increment`) batch size that get deployed to
an environment during every loop. Default: 4.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added a configurable load-test container increment input (default: 4)
to control scaling increments.
* **Improvements**
* Prevented destructive runs when an existing infra workspace matches
the requested name.
* Tightened workspace-existence checks to require exact name matching.
* **Chores**
* Default load-test increment reduced from 8 to 4 and input validated as
a positive integer.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Replace the two fixed daily cron entries (0 14 * * * and 0 21 * * *)
with a single every-4-hours schedule (0 */4 * * *) for
.github/workflows/ingest-maintained-apps.yml. This consolidates and
increases the ingest job frequency to run hourly at 4-hour intervals.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Updated the schedule for the maintained apps ingestion workflow to run
more frequently (every 4 hours instead of at fixed times).
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** For #44077
# Details
* Adds `historical_data` key to app and team config (and gitops) with
`uptime` and `vulnerabilities` subkeys. Keys default to `true`, meaning
"collect this data"
* Adds `enabled_historical_dataset` and `disabled_historical_dataset`
activities when these values are flipped via GitOps or the config APIs
The majority of the file changes in here are GitOps test files that need
to be updated to have the new config in them.
**This PR does _not_ implement using these configs to actually disable
data collection or purge data; that will come in a follow-up PR (as well
as the front-end)**
# 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, unreleased
## Testing
- [X] Added/updated automated tests
- [ ] QA'd all new/changed functionality manually
#### Defaults
- [X] Fresh install: `GET /api/v1/fleet/config` returns
`features.historical_data.uptime: true` and
`features.historical_data.vulnerabilities: true`
- [X] Created a new fleet via `POST /api/v1/fleet/teams`, then `GET
/api/v1/fleet/fleets/{id}` returns `features.historical_data.uptime:
true` and `features.historical_data.vulnerabilities: true`
#### Global PATCH (`POST /api/v1/fleet/config`)
- [X] PATCHed `{"features": {"historical_data": {"vulnerabilities":
false}}}` — `vulnerabilities` flipped to `false`, `uptime` unchanged at
`true`
- [X] PATCHed `{"features": {"historical_data": {"uptime": false,
"vulnerabilities": true}}}` — both values applied as sent
- [X] PATCHed `{"features": {"historical_data": {"vulnerabilites":
false}}}` (typo in sub-key) — request rejected with 4xx, stored config
unchanged
#### Fleet PATCH (`PATCH /api/v1/fleet/fleets/{id}`)
- [X] PATCHed a fleet with `{"features": {"historical_data": {"uptime":
false}}}` — fleet's `uptime` flipped to `false`, `vulnerabilities`
unchanged
- [X] Subsequent `GET /api/v1/fleet/fleets/{id}` returns the toggled
values under `features.historical_data` (storage shape is symmetric with
global)
- [X] PATCHed a fleet with `{"features": {"enable_host_users": false}}`
(a non-`historical_data` features sub-field) — request returned 200 but
the fleet's `enable_host_users` is unchanged (silently ignored, per
existing endpoint convention)
#### GitOps — global (`fleetctl gitops -f global.yml`)
- [X] Applied a YAML with `features.historical_data: {uptime: true,
vulnerabilities: false}` — `vulnerabilities` is `false` after apply,
`uptime` is `true`
- [X] Applied a YAML whose `org_settings` omits `features` entirely —
both sub-keys are `true` after apply (defaults injected even if
previously disabled)
- [X] Applied a YAML where `historical_data` only contains `uptime:
false` — `uptime: false` is honored, `vulnerabilities` defaults to
`true`
- [X] Disabled `vulnerabilities` via the API, then ran `fleetctl gitops`
with a YAML that doesn't pin it — `vulnerabilities` flips back to `true`
(this is intentional; gitops is the source of truth)
#### GitOps — fleet
- [X] Applied a fleet YAML with `features.historical_data: {uptime:
false}` — that fleet has `uptime: false`, `vulnerabilities: true` after
apply
- [X] Applied a fleet YAML whose `team_settings.features` omits
`historical_data` — both sub-keys are `true` after apply
- [X] Applied a fleet YAML that omits `features` entirely — both
sub-keys are `true` after apply
#### `fleetctl apply` (legacy, partial-merge)
- [ ] Disabled `vulnerabilities` via the API, then ran `fleetctl apply`
with a YAML that doesn't mention `historical_data` — `vulnerabilities`
is still `false` (apply leaves omitted fields alone)
#### Activities — global
- [X] After PATCHing global to disable `vulnerabilities`, the latest
activity is `disabled_historical_dataset` with payload `{"dataset":
"vulnerabilities", "fleet_id": null, "fleet_name": null}`
- [X] After PATCHing global with both sub-keys flipping in one request,
two activities are emitted (one per sub-key)
- [X] After PATCHing global with the same values that are already
stored, zero new activities are emitted
- [X] After re-enabling a previously disabled dataset, the activity type
is `enabled_historical_dataset`
#### Activities — per fleet
- [X] After PATCHing fleet `workstations` to disable `uptime`, the
activity is `disabled_historical_dataset` with payload `{"dataset":
"uptime", "fleet_id": <workstations id>, "fleet_name": "workstations"}`
- [X] Toggling the same dataset on two different fleets produces two
distinct activities, one per fleet
- [X] After a fleet PATCH with the same values already stored, zero new
activities are emitted
For unreleased bug fixes in a release candidate, one of:
- [X] Confirmed that the fix is not expected to adversely impact load
test results
- [ ] Alerted the release DRI if additional load testing is needed
## 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:
- [X] Verified that the setting is exported via `fleetctl
generate-gitops`
- [X] Verified the setting is documented in a separate PR to [the GitOps
documentation](https://github.com/fleetdm/fleet/blob/main/docs/Configuration/yaml-files.md#L485)
- https://github.com/fleetdm/fleet/pull/44703
- [X] 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)
- [X] Verified that any relevant UI is disabled when GitOps mode is
enabled
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Historical-data controls: per-org and per-team toggles for uptime and
vulnerability time‑series, with defaults applied when keys are omitted
and enable/disable activities emitted on changes.
* **Bug Fixes**
* Partial updates and PATCH/GitOps flows preserve unspecified
historical-data sub-keys instead of clearing them.
* **Tests**
* Expanded unit and integration tests covering defaults, partial
PATCH/GitOps behavior, idempotency, and activity emission.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Small QoL improvement. During standup, speccing, etc we check the board
for stories with open TODOs. There have recently been some TODOs added
in comments so while you can't find a TODO with ctrl+f if you edit the
markdown you'll find one. This just makes them "TO DOs" in the comments
so they don't get flagged by filtering for TODO if not removed. Actual
visual content of template left alone
Resolves: #34771
This moves away from relying on discontinued bitnami charts and instead
adds a small mysql chart, a valkey/redis chart and a brief guide update
on how to migrate from one to the other.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Helm chart bumped to v7.0.0.
* Replaced Redis with Valkey as the caching backend and added Valkey
configuration options.
* Added an optional embedded MySQL chart with configurable auth,
persistence, service, and credentials handling.
* **Chores**
* CI now adds the Valkey Helm repository and builds chart dependencies
before templating.
* .gitignore adjusted to only ignore packaged chart archives (*.tgz).
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: georgekarrv <1501415+georgekarrv@users.noreply.github.com>
- Disable performance insights
- Allow redis instance count >=1
- Properly set ecs_cluster logging config path
- Targeted apply with auto approve for pre-creating fleet and execution
roles
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Enhanced ECS cluster logging with CloudWatch integration and extended
log retention to 365 days.
* Adjusted RDS monitoring configuration and disabled performance
insights for operational optimization.
* Reduced minimum Redis instance requirement from 3 to 1 for greater
deployment flexibility.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Updated deployment workflow configuration to source Slack
notifications from the correct webhook endpoint.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
- We often encounter bugs where the expected behavior is clear, but the
Product Development team cannot provide a specific solution. It often
requires engineer (tech lead) to understand what's broken and provide
technical details in the "To fix" section.
- Some time ago, we added a requirement to change the bug title to
reflect the expected behavior rather than what is broken. I find this
approach counterintuitive and often confusing. Additionally, I believe
we haven't consistently followed this practice, despite it being
documented.
---------
Co-authored-by: Noah Talerman <47070608+noahtalerman@users.noreply.github.com>
This pull request introduces support for ingesting Homebrew casks from
third-party taps (not available in the official
`Homebrew/homebrew-cask`) into the Fleet Maintained Apps (FMA) system.
It does this by allowing cask metadata to be committed directly into the
repository and referenced via a new `cask_path` field. The PR also
updates CI workflows to better support Fleet Desktop validation and
documents the new contributor flow.
**Support for custom Homebrew casks:**
* Added a new `cask_path` field to app manifests, allowing the FMA
ingester to read cask metadata from a local JSON file instead of
fetching from the Homebrew API. This enables ingestion of apps from
third-party taps or custom casks not present in the official Homebrew
repository.
[[1]](diffhunk://#diff-be469dd148f0c50ad56489c48bdb514522e1a46d21336e8f747b5880d71a6d1bR49-R66)
[[2]](diffhunk://#diff-abd7db4bef16a062c1bd81f54a7c846f1e91b913a9fe9f87976c8075f39b8cd2R270-R276)
* Refactored the Homebrew ingester (`brewIngester`) to use a new
`fetchCask` helper, which reads from the local file if `cask_path` is
set, or falls back to the API otherwise. Includes robust error handling.
[[1]](diffhunk://#diff-abd7db4bef16a062c1bd81f54a7c846f1e91b913a9fe9f87976c8075f39b8cd2L99-R101)
[[2]](diffhunk://#diff-abd7db4bef16a062c1bd81f54a7c846f1e91b913a9fe9f87976c8075f39b8cd2R200-R251)
* Added comprehensive documentation and examples for the custom tap
workflow, including a new `custom-tap/` directory with cask DSL sources,
generated JSON, and a regeneration script.
[[1]](diffhunk://#diff-2dfa2fc79b9becad555db38289a16afe4ce651665a31868d386fed8b4e160740R1-R85)
[[2]](diffhunk://#diff-be469dd148f0c50ad56489c48bdb514522e1a46d21336e8f747b5880d71a6d1bR49-R66)
* Added new custom casks for `fleet-desktop`, `druva-insync`, and
`zoom-rooms` under `inputs/homebrew/custom-tap/Casks/`.
[[1]](diffhunk://#diff-2555a54830de2bfb0ffca8bc487aac67de84dee5d431fe5f42e90e1754f63bb6R1-R36)
[[2]](diffhunk://#diff-db1fa8a43a27c5adf49a5ade04e61405ce1e9420f266e3160156cabf69ed4ea8R1-R40)
[[3]](diffhunk://#diff-effd461583140683d41dc68d9a93692d039be5ad5e52b6b108ece79f17155107R1-R44)
**Testing and validation:**
* Added a new test (`TestIngestCaskPath`) to ensure the ingester
correctly reads from `cask_path` and does not make unnecessary HTTP
requests, with error handling for missing files.
**CI workflow improvements:**
* Updated GitHub Actions workflows to handle Fleet Desktop's installer
requirements in CI by creating a managed preferences stub when
validating Fleet Desktop, ensuring the installer succeeds even without
MDM enrollment.
[[1]](diffhunk://#diff-28b30c8601cb7662d59efbfbbcf800cae91455fd3d875627659dced8c1257a24R100)
[[2]](diffhunk://#diff-28b30c8601cb7662d59efbfbbcf800cae91455fd3d875627659dced8c1257a24R116-R123)
[[3]](diffhunk://#diff-28b30c8601cb7662d59efbfbbcf800cae91455fd3d875627659dced8c1257a24R148-R172)
[[4]](diffhunk://#diff-c263ffc3062c3b5e4e4eb65976080c6cbddac478a5fed3392fe8b23c49bb2da8R69-R92)
These changes make it possible to maintain and test apps from custom
Homebrew taps within the Fleet repo, improving flexibility and
reliability for Fleet-maintained apps.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added support for three new macOS apps: Fleet Desktop, Druva inSync,
and Zoom Rooms
* Added UI icons for Fleet Desktop and Zoom Rooms
* **Enhancements**
* Fleet Desktop includes an MDM enrollment caveat and improved installer
validation for macOS installers
* Support for overriding Homebrew cask input via a local cask JSON file
* **Tests**
* Added unit coverage for local cask JSON ingestion behavior
* **Chores**
* Added a deterministic script to regenerate Homebrew custom-tap
manifests
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Updated osqueryd version to 5.23.0 across macOS, Linux, and Windows
build processes.
* Adjusted release tooling behavior so the confirmation prompt only
appears when the corresponding branch/PR creation step will actually
run.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
FYI @AndreyKizimenko @chrstphr84 @xpkoala @Brajim20 @marko-lisica
@melpike as of 4.84, we want to make sure every new API endpoint is
available to be added to API-only users
Luke Heath
