Hi there, we’re seeing very large cache sizes with the pixi orb (CircleCI Developer Hub - prefix-dev/pixi). For example, this test run uses a 13 GB cache: CircleCI. I suspect there is a bug in the orb that causes the cache to grow indefinitely. If there is no cache key matching the pixi.lock file exactly, another key will be used to pre-populate the cache directories. Next the files matching the lock file will be added to the cache directories, and then the result (including all files from the previous cache), will be uploaded under a new cache key. Where do I report the issue? I see no link to a git repository on the orb page.
Good catch — and the behavior you’re describing matches how CircleCI’s cache restore/save works with prefix keys. When no cache key matches the lock file exactly, the nearest older cache is restored, the new files are layered on top, and the whole lot is saved again under the new key. Do that a few times and the cache snowballs, which fits the 13 GB you’re seeing.
Two workarounds that usually help: make the cache key exact, for example by basing it on a checksum of pixi.lock, so a changed lock file starts from an empty cache instead of layering on the old one; and if the orb allows it, clear the cache directory before the install step runs. Bumping the key prefix also forces a clean slate.
For reporting it, orbs are maintained by their publisher rather than CircleCI, so this one belongs with prefix-dev — the pixi project on GitHub is the right place to raise it, even though the orb page itself doesn’t link a repository. The 13 GB figure is worth leading with there; it makes it clearly a bug rather than normal cache growth.