Edit software - GitOps

[sharon-fdm]

Test plan (taken from enterprise_integration_test TestBatchSetSoftwareInstallersSideEffects):

To test: Need to set TEST_TEAM_NAME and SOFTWARE_INSTALLER_URL variables for team_software_installer_valid.yml and apply with the following command:

rachelperkins@RachelFleet build % fleetctl gitops -f ../cmd/fleetctl/testdata/gitops/team_software_installer_valid.yml

1. Create a team
2. Add a host on that team
3. Add a software installer
4. Start an install of the software on the host; execute steps 5-7 while still pending
5. Apply a GitOps update that switches the self-service flag
6. Confirm that the install is still pending, and uploaded_at on the installer is still the same
7. Apply a GitOps update that switches the preinstall query
8. Confirm that the install is blanked out (no longer pending)
9. Install the software; let it install
10. Apply a GitOps update that switches the install script
11. Confirm that the host still shows the software as installed
12. Change the installer that the URL in GitOps refers to
13. Apply a GitOps update (can be the same update as before)
14. Confirm that the host no longer shows the software as installed
15. Confirm that all installer status counts are zero
16. Confirm that uploaded_at has changed on the installer

• A pending install stays pending when changing self-service
• A pending install gets cleared when changing one of pre/install/post/uninstall
• Neither uploaded_at nor non-pending counts change when package contents don't change
• uploaded_at is updated and non-pending install counts are zeroed when package contents change

[iansltx]

Did some further research into this and software edits are handled by https://github.com/fleetdm/fleet/blob/main/docs/Contributing/API-for-contributors.md#batch-apply-software in GitOps, and that endpoint handles updates with PUT semantics on the entire collection of software, which works for that use case.

With that said, the existing endpoint doesn't cancel pending installs on changes to a title (or deletions), and unless I'm missing something doesn't update any counts.

@noahtalerman @lukeheath do we need to add these side effects to the existing batch endpoint? If we do, adding side effects should be the entirety of this issue. If not, I think we can close this as a noop since edits are already possible via GitOps.

[iansltx]

Based on discussions in standup today, adding the side effects seems to be the reasonable thing to do here, so this will stay open with adding side effects as the scope.

[noahtalerman]

@iansltx I think we want the experience here to be consistent across UI, API, and YAML.

As a user editing software, I expect to cancel pending installs.

It looks like we went this route which I think is a good call 👍

[iansltx]

Was going to include this in the PR with everything else, but it can be reviewed etc. independently, and I've already gotten reviews on backend for all other work on the branch, so will set this up as a separate branch/PR (though I'll reuse a lot of work from the main feature branch). This won't affect ETA (tonight/tomorrow morning).

[sharon-fdm]

QA UI/API - @RachelElysia
QA GitOps - @getvictor

[RachelElysia]

QA UI/API checklist finished and can be found in Story description #20404

[getvictor]

GitOps QA done

In addition to the testplan, also tested

• default scripts for install/uninstall appearing when these scripts are cleared out
• clearing out post-install script and pre-install query

[fleet-release]

GitOps shapes our code,
In the city of glass clouds,
Fleet adapts, unloads.

Software installer,
Changes, yet install persists,
Efficiency holder.

Script changes, in flight,
Yet software holds its install,
Improvement in sight.

Contents shift, we adapt,
Install counts reset to zero,
Progress in each step.