<!-- 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 -->
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.