The publisher runs on the provider's macOS machine and is a separate
workflow from the client. It carried its own Azure SAS and SigV4 S3
upload code, parallel uploads via ForEach-Object -Parallel with
helper functions injected through Invoke-Expression, an -UploadOnly
mode, and storage defaults read from the client's ElysiumSettings.txt
- all through the client's Elysium.Common.ps1 loader.
It now only builds the package (shards, manifest.json, khdb-clean.txt,
invalid-hashes.txt) and depends on nothing outside itself: no loader,
no relaunch, no settings file, no credentials. Uploading is left to
the storage provider's CLI, documented in the README for aws s3 /
rclone (S3-compatible) and azcopy (Azure): shards first, manifest
last, so a client never reads a manifest that points at shards that
are not there yet. -ShardRemotePrefix stays, since it is written into
the manifest and tells clients where to fetch shards from.
Removed: Upload-AzureBlob, Invoke-S3HttpUpload, the settings and
parallel-helper setup, the -UploadOnly branch and the upload section;
parameters StorageProvider, StorageAccountName, ContainerName,
SasToken, S3*, ManifestRemotePath, SkipUpload, UploadOnly,
MaxParallelTransfers, SettingsPath. 1,191 -> 770 lines. The shard
splitter and manifest writer are untouched.
BREAKING for the provider workflow only: existing invocations with
-SkipUpload or storage parameters now fail with "parameter cannot be
found"; clients are unaffected.
Verified: an AST check finds no calls to anything not defined in the
script or built into PowerShell; the publish -> update round-trip
test passes without -SkipUpload; 23/23 Pester tests pass.
tomas.kracmar
cb6431c82a