Files
fleet/.github/workflows
Scott Gress df44a9342e Use Docker as default WiX runtime on macOS arm64 (#43715)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or
remove if NA -->
**Related issue:** Resolves #43484

# Details

Apple Silicon Macs were being forced down the Wine+local-wix-dir path
because the fleetdm/wix:latest image was deemed unreliable on arm64 in
Jan 2024. Docker Desktop's amd64 emulation has matured since -- the
image builds both amd64 and arm64 MSIs on arm64 macOS successfully. This
PR:

- Drops the arm64-forces-Wine guard in BuildMSI so the Docker path is
the default on every macOS arch when --local-wix-dir isn't provided.
- Drops the macOS "Install wine and wix" + "Build MSI on macOS (using
local Wix)" CI steps. The ubuntu-latest matrix entry already exercises
the Docker path, and the install-wine.sh flow is brittle against Gcenx
release churn and homebrew-cask deprecation.
- Updates the install-wine.sh script to fail and output a message
indicating that Docker should be used, or else Wine installed manually.
```
============================================================
This script no longer installs Wine.
============================================================

Wine is no longer required to build Windows (.msi) packages on macOS.
fleetctl package now uses Docker by default on all macOS architectures.

RECOMMENDED: install Docker Desktop
  https://docs.docker.com/get-docker

If you cannot use Docker and still need to build MSIs with Wine on macOS
see the upstream WineHQ wiki for installation instructions:
  https://gitlab.winehq.org/wine/wine/-/wikis/MacOS

Automatic Wine installation via Homebrew is no longer attempted here
because the wine-stable cask is deprecated and upstream Wine releases
have caused repeated breakage.
```
- Retains the wix auto-download helper (downloadAndExtractZip,
extractZipFile, wixDownload) for backwards-compatibility when Docker
isn't detected, with a deprecation warning.

The Wine + --local-wix-dir path remains available for macOS users who
opt into it, but is no longer documented. See #43484.

# Checklist for submitter

If some of the following don't apply, delete the relevant line.

- [X] 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.

## Testing

- [X] Added/updated automated tests
- Dropped MacOS packaging tests. The Ubuntu test already exercises the
Docker path that MacOS now uses.
- [X] QA'd all new/changed functionality manually
  - Built and installed both amd64 and arm64 .msi packages successfully

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
* MSI packages on macOS now build using Docker by default, removing the
Wine dependency.

* **Documentation**
* Updated macOS setup guidance: Docker Desktop is now required for MSI
packaging instead of Wine.

* **Chores**
* Simplified Wine-related helper scripts and removed outdated
installation logic.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
2026-04-21 10:53:46 -05:00
..
2026-02-11 11:11:05 -07:00
2026-02-12 09:49:20 -06:00

Github Actions

Fleet uses Github Actions for continuous integration (CI). This document describes best practices and at patterns for writing and maintaining Fleet's Github Actions workflows.

Bash

By default, Github Actions sets the shell to bash -e for linux and MacOS runners. To help write safer bash scripts in run jobs and avoid common issues, override the default by adding the following to the workflow file

defaults:
  run:
    # fail-fast using bash -eo pipefail. See https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#exit-codes-and-error-action-preference
    shell: bash

By specifying the default shell to bash, some extra flags are set. The option pipefail changes the behaviour when using the pipe | operator such that if any command in a pipeline fails, that commands return code will be used a the return code for the whole pipeline. Consider the following example in test-go.yaml

    - name: Run Go Tests
      run: |
        # omitted ...
          make test-go 2>&1 | tee /tmp/gotest.log

If the pipefail option was not set, this job would always succeed because tee would always return success. This is not the intended behavior. Instead, we want the job to fail if make test-go fails.

Concurrency

Github Action runners are limited. If a lot of workflows are queued, they will wait in pending until a runner becomes available. This has caused issue in the past where workflows take an excessively long time to start. To help with this issue, use the following in workflows

# This allows a subsequently queued workflow run to interrupt previous runs
concurrency:
  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id}}
  cancel-in-progress: true

When a workflow is triggered via a pull request, it will cancel previous running workflows for that pull request. This is especially useful when changes are pushed to a pull request frequently. Manually triggered workflows, workflows that run on a schedule, and workflows triggered by pushes to main are unaffected.