⚠️ Breaking: Apple payload schema findings now fail the plan
A blueprint legacy_payloads finding (unknown payload type or key, wrong value type, missing
required key) was a warning. It is an error now. A Mac applies only the keys Apple defines for a
payload type, so a typo or a wrong-cased key installs and does nothing. Plan is where you can still
catch it.
If a key the embedded schema table does not carry starts failing your plan, move the payload to
raw_component to send it unchecked. That works per block, so every payload in the same
component_blocks entry moves with it.
Apple schema validation
Blueprints: apple_declarations
One attribute now carries Apple's declaration types. Jamf calls it "All Declarations" in the
blueprint editor and generates a form per type from Apple's DDM schemas. Author any of the 59 types
the provider's schema tables hold: 48 configurations, 7 assets, 3 management declarations and the
simple activation.
The eleven purpose-built components (passcode_policy, safari_settings, software_update and the
rest) work as before. Reach for apple_declarations for the rest, and for the asset and activation
kinds no other attribute in this resource touches.
A configuration names an asset by its position in the list through $PAYLOAD_n, so the order you
write carries meaning. The provider range-checks that reference at plan.
The provider now checks apple_declarations and custom_declarations against Apple's published
schemas at plan, so you see an unknown declaration type or key before you apply. Declaration keys
match case-sensitively. Findings are errors, and raw_component sends a declaration unchecked.
Both schema tables now union Apple's release branch with its newest seed_OS_* branch, so they
carry the seed-only keys the Jamf Pro interface offers. The generator runs daily.
Fixed: a blueprint using the deprecated top-level attributes dropped com.jamf.ddm-strict and
com.jamf.ai-governance out of state on read, and the next apply deleted them with no diff in the
plan.
AI Governance: policy updates carry the version last read
Terraform writes settings_json whole, so an update built on a stale read replaced every setting
another editor had made. Each update now sends the version Terraform last read. If someone wrote to
the policy in between, the apply stops and reports AI policy is not at the version Terraform last
read. Run a new plan: Terraform reads the other edit and shows you what you would overwrite. A
policy with no version recorded updates without the check, and the apply warns and names it.
Fixed: a CDN or WAF error page no longer empties your state
An HTML error page from a CDN, WAF or IP allowlist carries whatever status the edge chose, and
CloudFront chooses 404 among them. The provider read that as a deleted object, so a refresh that
hit one dropped live objects out of state while plan showed a clean set of creates and exit status 0.
The same page passed as an accepted ebook delete, as an absent UEM Connect integration, and at 500
as a finished blueprint delete. Each of those now keeps the object in state.
A blocked request also names your egress address, the detail Jamf Support needs to act on an
allowlist, and says your own proxy or firewall may be the one answering. A 5xx asks you to re-run
and confirms your credentials are fine.
Also in this release
jamfplatform-go-sdk v1.0.0, a module bump with no signature, type or enum changes. The gitleaks
secret-scanning workflow is gone.
What's Changed
- ci: drop the gitleaks secret-scanning workflow by @neilmartin83 in #421
- feat(ai-governance): make policy updates conditional on the version last read by @neilmartin83 in #422
- feat(blueprints): add apple_declarations and validate declarations against Apple's schemas by @neilmartin83 in #423
- chore(deps): SDK v1.0.0, and fix the state-clearing bugs it exposed by @neilmartin83 in #424
Full Changelog: v0.32.0...v0.33.0