replicatedhq
Include atomic preflight collector statuses
What type of PR is this?
type::feature (really more of a type::improvement as the UX isn't changing yet)
What this PR does / why we need it:
The preflights page displays a progress bar for status, but doesn't provide a lot of detail to the end user. As part of an effort from Grayson to improve the preflight status page, the preflight result handler should return more atomic info on collector statuses.
This PR sends back an array of all collectors and their current status (pending, running, completed, failed). The change should have no impact to preflights today, but will provide an opportunity for front-end improvements with the newly provided info.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?
NONE
Does this PR require documentation?
NONE
Relates to https://github.com/replicatedhq/troubleshoot/pull/534
https://app.shortcut.com/replicated/story/42665/kots-troubleshoot-show-atomic-statuses-on-preflight-checks-while-they-re-running
I'm curious to learn more about what this does. Will you update the description of the PR to describe what the change does, what problem is solves, what API or UX changes are part of it, and how it was tested?
Updated the PR description. This is an additive change to the API response - I've run a bunch of preflights as tests to prove A) the existing behavior is unchanged and B) the additional info is in the API response. The idea is to ship this change and allow UX work to happen async as Grayson becomes available. I've discussed the changes and outcomes of this PR with him to ensure we're aligned with the new data being delivered.
@jeffreygolden thanks, that makes sense. Since we will be relying on this functionality, should there be tests (unit and/or e2e) on the updated response structure?
My thought was to implement e2e testing on any preflight page changes as these values get implemented on the front-end. I think this return is still liable to change if Grayson needs anything changed as he works through the UX.
This code is a bit difficult to unit test as it's coupled very closely with troubleshoot functions, is directly linked to database operations, and doesn't have many public interfaces into the execute portion of the code. Let me know if you see any opportunities in the code that I'm missing though and I'm happy to implement some tests.