-
Notifications
You must be signed in to change notification settings - Fork 8.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Fleet] Don't auto upgrade policies for AUTO_UPDATE packages #115199
[Fleet] Don't auto upgrade policies for AUTO_UPDATE packages #115199
Conversation
Pinging @elastic/fleet (Team:Fleet) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀 How complicated it will be to add a unit test for that? (it could be a great way to document what we want to be auto upgraded, ...)
We do have a test now that I think has had its robustness improved by this PR: kibana/x-pack/plugins/fleet/server/services/managed_package_policies.test.ts Lines 35 to 80 in cba8333
I think this test gives us confidence that any package not flagged as Maybe a good way to improve coverage here would be to move the |
Ye it totally make sense |
💚 Build SucceededMetrics [docs]
History
To update your PR or re-run it, just comment with: cc @kpollich |
…#115199) * Don't auto upgrade policies for AUTO_UPDATE packages * Fix unused import * Improve test coverage for upgrade policies check
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
#115273) * Don't auto upgrade policies for AUTO_UPDATE packages * Fix unused import * Improve test coverage for upgrade policies check Co-authored-by: Kyle Pollich <kyle.pollich@elastic.co>
…-migrate-away-from-injected-css-js * 'master' of github.com:elastic/kibana: (237 commits) [Uptime] Added uptime query inspector panel (elastic#115170) [Osquery] Add packs (elastic#107345) [App Search] Allow for query parameter to indicate ingestion mechanism for new engines (elastic#115188) [Alerting] Active alerts do not recover after re-enabling a rule (elastic#111671) skip flaky tests. elastic#115308, elastic#115313 [Breaking] Remove deprecated `enabled` settings from plugins. (elastic#113495) skip flaky suite. elastic#107057 skip flaky tests. elastic#89052, elastic#113418, elastic#115304 skip flaky test. elastic#113892 Bump node to 16.11.1 (elastic#110684) [Security Solution] Restores Alerts table local storage persistence and the Remove Column action (elastic#114742) skip flaky suite. elastic#115130 one line remove assert (elastic#115127) Fixes migration bug where I was deleting attributes (elastic#115098) [Security Solutions] Fixes the newer notification system throttle resets and enabling immediate execution on first detection of a signal (elastic#114214) [build] Dockerfile update (elastic#115237) Fixes Cypress flake cypress test (elastic#115270) Disable APM e2e tests log an invalid type for SO (elastic#115175) [Fleet] Don't auto upgrade policies for AUTO_UPDATE packages (elastic#115199) ... # Conflicts: # src/plugins/dashboard/public/application/dashboard_app.tsx # src/plugins/dashboard/public/types.ts # x-pack/plugins/reporting/server/lib/layouts/print_layout.ts
Summary
Ref #114914 (review)
We had an error in our logic for automatic package policies update via the
keep_policies_up_to_date
flag that incorrectly upgraded policies for any package flagged asAUTO_UPDATE
inkibana/x-pack/plugins/fleet/common/constants/epm.ts
Lines 42 to 46 in 50e4ae7
It feels like this should have been caught by our unit tests, but I'm not sure whether we should try to mock this
AUTO_UPDATE_PACKAGES
list, or use a "hardcoded" package name in our tests. Open to suggestions here, as I would like to make sure this case is covered by automated tests.