Conditions and Skipping

Conditions and Skipping

Gating in this build is one key with two accepted values. If you are looking for conditional items in the Munki sense, or for an "already installed, skip it" check, they are not here. This page states exactly what exists and what admins do instead.

The condition key

condition is a string on an item. It is not an expression language and it is not evaluated; two substring tests are run against it and everything else in the string is ignored.

Substring	Item is skipped when
architecture_x64	The OS architecture is not X64
architecture_arm64	The OS architecture is not ARM64

Both tests run, in that order, on the same string. A condition containing neither substring never skips anything, and neither does an item with no condition at all — the default is to install.

{
  "name": "Design Suite (x64)",
  "url": "https://example.com/bootstrap/packages/DesignSuite-x64.msi",
  "file": "DesignSuite-x64.msi",
  "type": "msi",
  "condition": "architecture_x64"
}

Ship the same item twice, once per architecture, with a different url, file and condition, to deliver an architecture-specific payload.

What "architecture" means here

The comparison uses the OS architecture, not the process architecture, deliberately: an x64 build of BootstrapMate running under ARM64 emulation still reports ARM64 and still gets the ARM64 items. The value is uppercased before comparison, and the two names that matter are X64 and ARM64.

An X86 device matches neither substring, so an item carrying either condition is skipped on it.

How a skip is reported

A skipped item logs at Debug:

Skipping {name} - x64 condition not met on {architecture} architecture

and writes a [SKIPPED] marker line at Info:

[SKIPPED] Skipping - x64 condition not met on {architecture}

Grep for [SKIPPED] to find every architecture skip in a run. In the progress dialog the item is marked with the text Architecture mismatch, but using the success state — there is no distinct skipped state in the dialog, so a skipped item looks installed to whoever is watching the screen. A skip does not fail the item, the phase or the run.

What does not exist

Being explicit, because several of these are things an admin arriving from Munki, Cimian or InstallApplications will reasonably expect:

• No installs array, receipt check, file check or version comparison. Nothing detects that an item is already installed. packageid is accepted by the parser and never acted on.
• No skip_if/skipIf. The macOS build uses skipIf for exactly this job; the key name here is condition and the accepted values differ.
• No OS version, hostname, domain, group, model or registry conditions.
• No required flag, no dependencies, no donotwait. Every item is attempted, and a failure is logged and stepped over.
• No way to gate a whole phase. The only phase-level control is leaving the key out of the manifest, which records it as Skipped.
• No preflight stage. On macOS a preflight script can end a run before it starts; this build ignores the key entirely.

What admins do instead

Put the condition inside a ps1 item. A script item can test anything you like and exit 0 when there is nothing to do. Since a non-zero exit is the only failure signal, a script that decides to do nothing must exit 0, or the item is reported as failed. This is the general answer for "install only if", "configure only when", and anything OS-version dependent.

Gate the whole run from the deployment layer. BootstrapMate is normally delivered as a required Win32 app, so the app's requirement rules and assignment decide which devices run it at all. That is the right place for model, OS build and group conditions.

Use a detection script to decide whether the run should happen again. The repository ships three examples under examples/detection-scripts/, and they are worth reading — but not deploying as-is. All three compare LastRunVersion to a version string hard-coded in the script, and they read it from HKLM:\SOFTWARE\BootstrapMate, which is written by the MSI at install time. The value a successful run writes lives under HKLM\SOFTWARE\Cimian\BootstrapMate instead. As shipped they detect that the MSI is installed, not that a bootstrap completed, and the hard-coded version means they report a mismatch out of the box. Write your detection against the real key:

(Get-ItemProperty 'HKLM:\SOFTWARE\Cimian\BootstrapMate\Status\SetupAssistant').Stage

See Troubleshooting and Gotchas for the rest of that registry mismatch, and https://github.com/bootstrapmate/bootstrapmate-macintosh/wiki/Conditions-and-Skipping for the macOS model, which also covers the already-installed check this build does not have.

See also

• Manifest Reference
• Item Types
• Stages
• Deployment
• Troubleshooting and Gotchas