fix(deployments): scope sourceSize to the extracted tree, not the provider archive - #13614
Open
breken-ai wants to merge 1 commit into
Open
fix(deployments): scope sourceSize to the extracted tree, not the provider archive#13614breken-ai wants to merge 1 commit into
breken-ai wants to merge 1 commit into
Conversation
…vider archive For git-source deployments the provider archive spans the whole repository, so recording its byte size as sourceSize inflated every monorepo deployment (and the storage totals that sum it) with the rest of the repo. Stat the extracted tree instead - already scoped to rootDirectory with the forge wrapper stripped. Stat rejects directories, so re-pack 'source' into a plain tar via ArchiveArtifact first. Fixes appwrite#13586
Contributor
 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| // extracted tree instead, already scoped to rootDirectory with | ||
| // the forge wrapper stripped. Stat rejects directories, so | ||
| // re-pack 'source' into a plain tar first. | ||
| new ArchiveArtifact(id: 'sourceSizeArchive', in: 'source', out: 'source-size.tar', format: ArchiveFormat::Tar, depends: 'extract'), |
Contributor
There was a problem hiding this comment.
This accounting change has no observable regression test for a VCS deployment with rootDirectory. Existing coverage only checks that sourceSize is positive and contributes to totalSize, so it would still pass if this code reverted to measuring the whole provider archive. Add a deployment-level test showing that large files outside the selected root do not affect the reported source size or deployment-storage total, without asserting the artifact pipeline itself.
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/Appwrite/Deployment/Deployments.php
Line: 407
Comment:
**Scoped accounting lacks coverage**
This accounting change has no observable regression test for a VCS deployment with `rootDirectory`. Existing coverage only checks that `sourceSize` is positive and contributes to `totalSize`, so it would still pass if this code reverted to measuring the whole provider archive. Add a deployment-level test showing that large files outside the selected root do not affect the reported source size or deployment-storage total, without asserting the artifact pipeline itself.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
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
2 participants
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.
Fixes #13586.
Root cause (the reporter's, confirmed at HEAD)
@AlimFreight traced this; verified independently:
Deployments.php(~:398-409): the VCS path downloads the whole-repo provider archive, andStatArtifact(id: 'sourceSize', in: 'source.tar.gz')records the entire archive - while the extracted tree is already scoped torootDirectoryviasubdir+strip.Workers/Jobs.php:308-319: the worker writes that stat intosourceSize/totalSize.Workers/StatsResources.php:262/290/307:sum(sourceSize)becomesDEPLOYMENTS_STORAGE, withsourcePathNULL on VCS deployments so nothing corrects it - the reporter's ~525MB phantom across 94 functions.Sharpening (confirmed): deployments reporting
sourceSizeall went through the archive path (the clone path reports none), and forge archives carry no.git- so this is whole-repo-archive vs subdirectory, not a.giteffect. The reporter's numbers back it (4.33MB reported vs ~4.46MB whole-worktree estimate).Fix (1 file, +11/-4)
Re-pack the extracted,
rootDirectory-scoped tree into a plain tar and stat that instead:ArchiveArtifact(id: 'sourceSizeArchive', in: 'source', out: 'source-size.tar', format: Tar, depends: 'extract')StatArtifact(id: 'sourceSize', in: 'source-size.tar', depends: 'sourceSizeArchive')Only existing orchestrator primitives are used -
Stat.Applyrejects directories,Archive.Applypacks them (both verified in the orchestrator Go source), andArchiveArtifact/ArchiveFormat::Tarexist inopen-runtimes/sdk-for-php0.13.0, which appwrite pins. Zero orchestrator or SDK changes.Semantic change (disclosed)
sourceSizebecomes uncompressed subdir bytes (+512B/file tar overhead) instead of compressed whole-repo bytes; existing rows keep inflated values until the next redeploy. Alternative for maintainers who prefer minimal blast radius: gate the threeStatsResources.phpsums onsourcePath IS NOT NULL- a one-liner that fixes accounting but leaves per-deployment display wrong, hence the artifact fix instead.Verification
Every step re-traced in source at
main(f31509d) plus the orchestrator (Go) and sdk-for-php 0.13.0 pinned ref. Not run: no PHP runtime or live Appwrite/orchestrator build in the author's environment - the reporter offered to verify storage totals after a redeploy.Overlap note: this touches
src/Appwrite/Deployment/Deployments.php(:395-409), about 200 lines from #13589's change (:182) in the same file; both apply independently against current main, but whichever lands second will need a trivial rebase.