Add linux-arm64 targets to orbit

[dantecatalfamo]

#1845

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)
• [ ] Added support on fleet's osquery simulator cmd/osquery-perf for new osquery data ingestion features.
• [ ] Added/updated tests
• [ ] If database migrations are included, checked table schema to confirm autoupdate
• For 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).
• [ ] Manual QA for all new/changed functionality
  • For Orbit and Fleet Desktop changes:
    • [ ] Manual QA must be performed in the three main OSs, macOS, Windows and Linux.
    • [ ] Auto-update manual QA, from released version of component to new version (see tools/tuf/test).

[dantecatalfamo]

Getting the amd64 runners to successfully execute the arm64 binary to test osqueryd has been really interesting

[dantecatalfamo]

I've tried running qemu-user-static to execute binaries compiled for other architectures in local docker for both amd64 and arm64 and it works both ways. For whatever reason the machines that we're running here for the actions seem to not want to work. Having a hard time figuring out why 🤔

[dantecatalfamo]

@lukeheath The software and workflow support for this is complete, the only thing it is waiting on for local TUF server use is pushing the arm64 osqueryd to the fleet TUF server so that it can be fetched using the create_repository.sh script. It is also pending the other components being pushed to the fleet TUF server for mainstream use.

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 9.58904% with 66 lines in your changes missing coverage. Please review.

Project coverage is 37.13%. Comparing base (fceff75) to head (baf01f0). Report is 75 commits behind head on main.

Files	Patch %	Lines
orbit/pkg/update/update.go	0.00%	29 Missing :warning:
orbit/pkg/packaging/linux_shared.go	0.00%	15 Missing :warning:
cmd/fleetctl/package.go	37.50%	10 Missing :warning:
orbit/pkg/update/options.go	0.00%	6 Missing :warning:
orbit/cmd/orbit/orbit.go	0.00%	5 Missing :warning:
ee/fleetctl/updates.go	50.00%	1 Missing :warning:

Additional details and impacted files

@@             Coverage Diff             @@
##             main   #19931       +/-   ##
===========================================
- Coverage   62.65%   37.13%   -25.53%     
===========================================
  Files        1405     1414        +9     
  Lines      131562   132740     +1178     
  Branches     3216     3216               
===========================================
- Hits        82429    49289    -33140     
- Misses      42810    79020    +36210     
+ Partials     6323     4431     -1892     

Flag	Coverage Δ
backend	35.66% <9.58%> (-27.76%)	:arrow_down:

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[dantecatalfamo]

Still awaiting code owners approval

[lucasmrod]

Also, double checking you have tested auto-updating orbit and Fleet Desktop to a "N+2" version, meaning these changes are not breaking the auto-update mechanism.

IOW, you auto-update latest released orbit to an orbit version with the changes in this PR, then update some dummy string in orbit (to make the executable different) and push another update (effectively updating to a "N+2" version).

Let me know if it makes sense.

[dantecatalfamo]

I haven't intentionally tested N+2, although while I'm working on orbit, I have a script that recompiles and pushes my changes to my local tuf server every time I save, and the client keeps updating without issue

[lucasmrod]

https://github.com/fleetdm/fleet/actions/runs/9881234629/job/27291579818?pr=19931 looks like a network issue in the Github action, maybe try re-running the failed one?

[lucasmrod]

And https://github.com/fleetdm/fleet/actions/runs/9881234628/job/27291578960?pr=19931 is a known flaky test due to Colima timeouts in Github runners.

[dantecatalfamo]

Yeah the macos specific actions often have odd flaky issues

[dantecatalfamo]

Looks ready to merge, apparently pending one review