-
Notifications
You must be signed in to change notification settings - Fork 3
Installomator Integration
Third Party Patcher uses Installomator label files to identify, download, and install third-party applications. Each label is a zsh fragment that defines variables like name, type, downloadURL, expectedTeamID, and appNewVersion for one specific application.
Patcher does not use the Installomator script itself as a black box — it reads the label files directly to discover apps and check versions, then invokes patcher binary for the actual installation step.
Labels are stored at:
/Library/Application Support/Patcher/Installomator/Labels/
/Library/Application Support/Patcher/Installomator/Version.txt
The Version.txt file contains the git commit hash of the Installomator release the labels were pulled from. Patcher compares this hash to the latest release on GitHub to decide whether to update.
On each scheduler wake, Patcher checks the configured GitHub repository for a newer release of the labels. If a new version is available, it downloads and extracts the updated label files.
Configuration:
| Key | Default | Description |
|---|---|---|
InstallomatorGitHubAccount |
"Installomator" |
GitHub account |
InstallomatorGitHubRepo |
"Installomator" |
GitHub repository |
InstallomatorGitHubBranch |
"main" |
Branch to pull from |
InstallomatorUpdateDisable |
false |
Disable automatic updates while keeping existing labels |
InstallomatorLabelsDisable |
false |
Disable Installomator entirely; rely solely on Managed Labels |
Tip: Point to your own fork of Installomator using
InstallomatorGitHubAccountandInstallomatorGitHubRepo. This is useful if you need to pin to a specific version or maintain customized labels centrally without using the Managed Labels feature.
Set InstallomatorLabelsDisable to true if you want to manage labels entirely yourself via Managed Labels:
<key>InstallomatorLabelsDisable</key>
<true/>When this is set, Patcher will not download, update, or read from the Installomator Labels folder. Only your Managed Labels are used. If no Managed Labels are present, the scheduler will log a warning and skip all phases that require labels.
Patcher tracks a combined "effective labels version" that incorporates both the Installomator version and the Managed Labels version (see Managed Labels). When either changes:
-
ScanOnLabelUpdatetriggers an immediate scan (if enabled). - Any labels that previously failed to resolve (broken labels) are rechecked.
This means that updating your Managed Labels Version.txt is sufficient to force a recheck of previously broken labels in your managed set.
Patcher evaluates each label in a sandboxed zsh environment to extract metadata without running the full Installomator installation flow. The INSTALL variable is set to "force" to suppress tool helper execution during evaluation.
Fields extracted per label:
| Field | Use |
|---|---|
name |
Display name |
appName |
.app bundle filename for discovery |
targetDir |
Install location (if non-standard) |
appNewVersion |
Latest available version |
appCustomVersion |
Function to determine installed version |
expectedTeamID |
Code signature validation |
blockingProcesses |
Process names that must not be running during install |
type |
Installer type (pkg, dmg, zip, etc.) |
downloadURL |
Direct download URL |
Occasionally a label may report a newer appNewVersion that doesn't correspond to what is actually installed after applying. This can cause Patcher to repeatedly download and discard the installer on every stage cycle (the Spotify problem).
When Patcher detects that a staged install did not bring the installed version to the expected version, it activates a throttle for that label:
- The label is skipped during stage for
VersionMismatchThrottleDays(default: 3 days). - The throttle is automatically cleared when the label reports a different
appNewVersion, indicating a genuine new release is available.
Configuration:
| Key | Default | Description |
|---|---|---|
VersionMismatchThrottleDays |
3 |
Days to suppress re-staging after a version mismatch |
IgnoredLabels — Skip specific labels entirely, even if the app is installed:
<key>IgnoredLabels</key>
<string>adobe* microsoftteams googlechrome</string>Wildcards (*) are supported. Useful for apps managed by other tools (Munki, Mosyle Apps, etc.).
RequiredLabels — Always manage specific labels, even if the app is not currently installed:
<key>RequiredLabels</key>
<string>zoom slack microsoftteams</string>No wildcards. Use this to ensure critical apps are always present and up to date.