Repository navigation
feat(pro): packages upload goes straight to JCDS on a gateway profile whose distribution point is Jamf Cloud - #461
Merged
neilmartin83 merged 2 commits intoOct 29, 2026
Conversation
… whose distribution point is Jamf Cloud
On the platform gateway a package upload is throttled by the gateway's
per-stream HTTP/2 window. When the tenant's cloud distribution point is
JAMF_CLOUD, send the binary to JCDS storage with jcdsupload.Upload (POST
/pro/v1/jcds/files, then S3) instead of POST /v1/packages/{id}/upload. The
existing refresh-inventory and hash verification poll is unchanged.
Only a gateway profile on JAMF_CLOUD takes the direct route. Instance
profiles, other CDN types, unknown types and a failed read of the
distribution point keep the API upload, because the direct route strands
the file in JCDS storage on any other distribution point.
A distribution point of NONE (or no record) is refused before the package
record is created, since the upload could never be verified.
Pins jamfplatform-go-sdk at v1.10.1-0.20261027182702-f6cb506dcae4, the
commit terraform-provider-jamfplatform uses, until a release carries
jcdsupload.
Wire-checked on an EU JAMF_CLOUD tenant with 1 MiB and 3 GiB files.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Replaces the pseudo-version of the commit that first carried jcdsupload. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
neilmartin83
force-pushed
the
feat/package-jcds-direct-upload
branch
from
October 28, 2026 18:17
db5435c to
efb7176
Compare
grahampugh
approved these changes
Oct 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
On a platform gateway profile whose cloud distribution point is
JAMF_CLOUD,pro packages uploadnow sends the binary to JCDS storage with the SDK'sjcdsupload.Upload(POST /pro/v1/jcds/files, then S3) instead ofPOST /v1/packages/{id}/upload. The gateway is out of the data path, so its per-stream HTTP/2 window no longer limits the transfer. The existing refresh-inventory and hash-verification poll is unchanged. Same behaviour as terraform-provider-jamfplatform'sfeat/package-jcds-direct-upload.pro_packages_upload_route.go): the direct route needs the Platform SDK client, which exists only under gateway auth. It is taken only on a positiveJAMF_CLOUDmatch. Instance profiles, other CDN types, unknown types and a failed read of the distribution point keep the API upload, because on any other distribution point the direct route leaves the file in JCDS storage and the record never links to it.NONE(or no record) is refused before the package record is created, since the upload could never be verified. A failed read does not refuse.jamfplatform-go-sdkv1.11.0.Stacked on
fix/gateway-upload-content-length; retarget tomainonce that merges.Test plan
go test ./...,go vet,gofmtJAMF_CLOUDtenant (gateway profile) with-v: 1 MiB and 3 GiB files.GET /cloud-distribution-point, thenPOST /jcds/files, no/packages/{id}/upload; the 3 GiB run saw three 504s from refresh-inventory, then 204, and verified with a matching SHA3-512Known: the SDK prints its own "returned Deprecation header" line to stderr on each direct upload. The CLI retry loop the provider has for failed uploads and the provider's NONE wording are not ported verbatim.
🤖 Generated with Claude Code