Allen Houchins
6ff485fcdd
This pull request introduces support for ingesting Homebrew casks from third-party taps (not available in the official `Homebrew/homebrew-cask`) into the Fleet Maintained Apps (FMA) system. It does this by allowing cask metadata to be committed directly into the repository and referenced via a new `cask_path` field. The PR also updates CI workflows to better support Fleet Desktop validation and documents the new contributor flow. **Support for custom Homebrew casks:** * Added a new `cask_path` field to app manifests, allowing the FMA ingester to read cask metadata from a local JSON file instead of fetching from the Homebrew API. This enables ingestion of apps from third-party taps or custom casks not present in the official Homebrew repository. [[1]](diffhunk://#diff-be469dd148f0c50ad56489c48bdb514522e1a46d21336e8f747b5880d71a6d1bR49-R66) [[2]](diffhunk://#diff-abd7db4bef16a062c1bd81f54a7c846f1e91b913a9fe9f87976c8075f39b8cd2R270-R276) * Refactored the Homebrew ingester (`brewIngester`) to use a new `fetchCask` helper, which reads from the local file if `cask_path` is set, or falls back to the API otherwise. Includes robust error handling. [[1]](diffhunk://#diff-abd7db4bef16a062c1bd81f54a7c846f1e91b913a9fe9f87976c8075f39b8cd2L99-R101) [[2]](diffhunk://#diff-abd7db4bef16a062c1bd81f54a7c846f1e91b913a9fe9f87976c8075f39b8cd2R200-R251) * Added comprehensive documentation and examples for the custom tap workflow, including a new `custom-tap/` directory with cask DSL sources, generated JSON, and a regeneration script. [[1]](diffhunk://#diff-2dfa2fc79b9becad555db38289a16afe4ce651665a31868d386fed8b4e160740R1-R85) [[2]](diffhunk://#diff-be469dd148f0c50ad56489c48bdb514522e1a46d21336e8f747b5880d71a6d1bR49-R66) * Added new custom casks for `fleet-desktop`, `druva-insync`, and `zoom-rooms` under `inputs/homebrew/custom-tap/Casks/`. [[1]](diffhunk://#diff-2555a54830de2bfb0ffca8bc487aac67de84dee5d431fe5f42e90e1754f63bb6R1-R36) [[2]](diffhunk://#diff-db1fa8a43a27c5adf49a5ade04e61405ce1e9420f266e3160156cabf69ed4ea8R1-R40) [[3]](diffhunk://#diff-effd461583140683d41dc68d9a93692d039be5ad5e52b6b108ece79f17155107R1-R44) **Testing and validation:** * Added a new test (`TestIngestCaskPath`) to ensure the ingester correctly reads from `cask_path` and does not make unnecessary HTTP requests, with error handling for missing files. **CI workflow improvements:** * Updated GitHub Actions workflows to handle Fleet Desktop's installer requirements in CI by creating a managed preferences stub when validating Fleet Desktop, ensuring the installer succeeds even without MDM enrollment. [[1]](diffhunk://#diff-28b30c8601cb7662d59efbfbbcf800cae91455fd3d875627659dced8c1257a24R100) [[2]](diffhunk://#diff-28b30c8601cb7662d59efbfbbcf800cae91455fd3d875627659dced8c1257a24R116-R123) [[3]](diffhunk://#diff-28b30c8601cb7662d59efbfbbcf800cae91455fd3d875627659dced8c1257a24R148-R172) [[4]](diffhunk://#diff-c263ffc3062c3b5e4e4eb65976080c6cbddac478a5fed3392fe8b23c49bb2da8R69-R92) These changes make it possible to maintain and test apps from custom Homebrew taps within the Fleet repo, improving flexibility and reliability for Fleet-maintained apps. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added support for three new macOS apps: Fleet Desktop, Druva inSync, and Zoom Rooms * Added UI icons for Fleet Desktop and Zoom Rooms * **Enhancements** * Fleet Desktop includes an MDM enrollment caveat and improved installer validation for macOS installers * Support for overriding Homebrew cask input via a local cask JSON file * **Tests** * Added unit coverage for local cask JSON ingestion behavior * **Chores** * Added a deterministic script to regenerate Homebrew custom-tap manifests <!-- 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.