Repository navigation
Conversation
Same gzip-in-place + --content-encoding gzip pattern as the local docs preview upload. The assembler tree is ~2 GiB of uncompressed HTML; pre-compressing before aws s3 sync cuts wire cost to ~120 MB. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Requesting changes: the upload step should fail on any compression discovery error (enable pipefail or equivalent) to avoid publishing non-gzip bytes with gzip content-encoding metadata.
What is this? | From workflow: PR Review
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
| # Pre-compress all non-zip files so aws s3 sync ships ~120 MB instead of ~2 GiB. | ||
| # Zip bundles (llm.zip, okf.zip) are already compressed; syncing them with | ||
| # content-encoding:gzip would prevent clients from decoding them correctly. | ||
| find ".artifacts/assembly/${ASSEMBLER_PREVIEW_PATH_PREFIX}" -type f ! -name "*.zip" -print0 \ |
There was a problem hiding this comment.
[MEDIUM] Fail the step if any pre-compression discovery fails
This pipeline can succeed even when find fails, because GitHub Actions runs bash -e but not pipefail by default. In find ... | xargs ..., the pipeline status comes from xargs; a partial find error can be masked, leaving some files uncompressed while the next sync still applies --content-encoding gzip to all non-zip files.
That can publish incorrectly encoded objects (clients receive non-gzip bytes labeled as gzip). Please enable set -o pipefail before this pipeline (or refactor to avoid a pipeline) so any find failure stops the upload.
GitHub Actions runs bash -e but not pipefail by default. In 'find ... | xargs gzip', the pipeline exit status comes from xargs, so a partial find failure is masked. Without pipefail, some files can be left uncompressed while aws s3 sync still applies --content-encoding gzip, publishing non-gzip bytes with incorrect encoding metadata. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
No new findings; approving.
What is this? | From workflow: PR Review
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
…r-preview # Conflicts: # .github/workflows/assembler-preview.yml
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Pre-compresses the assembler preview S3 upload so the wire cost drops from ~2.0 GiB to ~120 MB per preview run.
Affects: Deploys & previews, Automation
Why
Each API operation page is ~420 KB uncompressed (89% sidebar nav). At 4,029 pages the raw upload is ~1.7 GiB. CloudFront already serves with
content-encoding: gzipon the fly, but the origin upload still pays the full uncompressed byte count. Storing pre-compressed objects lets CloudFront forward them untouched at ~120 MB.What
Pre-compressed upload with zip exclusion
All non-zip files are gzip-compressed in place using
find ... ! -name "*.zip"piped to parallelgzip. Each file is compressed to amktemp-generated temp path then atomically renamed, avoiding collisions when bothfooandfoo.gzexist in the tree. Zip bundles (llm.zip,okf.zip) are excluded from compression and synced in a separate pass withoutcontent-encoding: gzipso clients receive raw zip bytes.Verify
Trigger the assembler preview workflow on a PR. The
Upload assembled docs to S3step should complete in seconds rather than minutes. Verify a preview page renders correctly in a browser and that downloadingllm.ziporokf.zipfrom the preview URL produces a valid zip archive.Supersedes #4210.
🤖 Generated with Claude Code