What it doesBasics
- Isolated package capture
- Shared-library bundling for Python, Ruby, and PHP
- BLAKE3 integrity checks
- Package inspection
- Resumable authenticated publishing
First useBasics
- Build and inspect one tool package before deciding whether to publish it.
- Inspect and verify the generated package.
- Publish it for signed distribution through the configured channel.
Everyday tasksEveryday use
Publish a verified tool package
A release engineer needs to add a tool version to the package channel used by reproducible workspaces.
- Select the tool identity and target platform and architecture, then capture from its verified source.
- Inspect the generated package and manifest for expected commands, files, size, and target identity.
- Run package verification before any upload.
- Publish through the authenticated channel; confirm whether the Hub signature was retrieved into the local manifest.
What you getThe channel receives an artifact whose contents and identity were checked before publication.
How to check: Build, inspect, and verify reports plus successful chunk completion identify the artifact, and a retrieved Hub signature stored locally adds further evidence.
Recover a large package upload
A large tool distribution is interrupted during publication and should not restart from its first byte.
- Keep the verified local package and manifest unchanged after the interruption.
- Confirm channel, credentials, target identity, chunk size, retry policy, and timeouts.
- Repeat publication so the hub reports already accepted chunks and upload resumes from the remaining range.
- Verify completion. If signature retrieval warned after successful publication, rerun the unchanged publish so upload is skipped and retrieval is retried.
What you getPublication continues from verified chunk state instead of rebuilding or re-uploading the entire artifact.
How to check: Resume status identifies accepted chunks and each remaining chunk passes BLAKE3 verification; final metadata matches the package, with a local signature recorded when retrieval succeeds.
Settings to decideAdvanced
- Choose isolated or direct capture
- Use Docker capture for the normal isolated, reproducible path. Select direct capture only in a controlled build environment that intentionally owns the local AIDC installation state.
- Declare target platform and architecture
- Set the package target independently from the machine running AIDC Pack, and preserve the same target identity through build, inspect, verify, and publish.
- Choose durable package storage
- Use a storage path with capacity for captured files, package output, and manifests. Retain unchanged artifacts when an upload must resume.
- Tune chunking and timeouts for the artifact
- Keep bounded retries and choose chunk and timeout values appropriate to artifact size and network conditions, and fix identity or integrity failures at their source.
CommandsAdvanced
Problems and fixesHelp
Good to knowHelp
- AIDC Pack runs on supported Linux hosts and can also target supported Darwin identities.
- Standard tools use AIDC source verification; Android components use their documented sdkmanager capture path.
- Rerunning an unchanged publish retries the local signature fetch.