fix(ci): apt-archive cache restore was silently failing on every run - #403
Conversation
Real CI evidence from main's post-#402-merge Build job: the cache restore genuinely found the key ("Cache hit for: apt-playwright-chromium-deps-v1") but tar extraction then failed with "Permission denied" on every single .deb file, immediately followed by "Cache not found for input keys" -- actions/cache's restore step runs as the unprivileged runner user, but /var/cache/apt/archives is root-owned by default. This means every apt-cache added in PR #398 across all 7 sites (6 in ci.yml, 1 in cef-learning-harness.yml) has been silently degrading to a full cache miss on every single run since it was introduced, undermining the whole point of that fix and very plausibly contributing to several of today's apt-mirror-timeout failures that were attributed purely to external throughput. Fix: chmod the archive directory world-writable (sudo, matching how the actual apt-get install steps already need sudo) immediately before each cache-restore step, so tar's unprivileged extraction can actually write into it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
ⓘ Qodo reviews are paused because your trial has ended. Ask your workspace admin to add credits to resume reviews. Manage billing |
🤖 CodeAnt AI — Review Status
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. |
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Reviewer's GuideEnsure GitHub Actions apt archive cache restores succeed by making the apt cache directory writable to the unprivileged runner user before each actions/cache restore that targets /var/cache/apt/archives in CI workflows. Sequence diagram for fixed apt archive cache restore in CIsequenceDiagram
participant runner
participant sudo
participant apt_cache_dir
participant actions_cache
participant apt_get
runner->>sudo: run_mkdir_p_var_cache_apt_archives_partial
sudo-->>apt_cache_dir: mkdir /var/cache/apt/archives/partial
runner->>sudo: run_chmod_R_777_var_cache_apt_archives
sudo-->>apt_cache_dir: chmod -R 777 /var/cache/apt/archives
runner->>actions_cache: actions_cache_restore
actions_cache->>apt_cache_dir: tar_extract_cached_debs
alt [apt_cache_dir writable]
actions_cache-->>runner: cache_restored_successfully
else [apt_cache_dir not writable]
actions_cache-->>runner: cache_not_found_after_permission_denied
end
runner->>apt_get: apt_get_install_with_deps
apt_get-->>apt_cache_dir: read_debs_from_cache
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
🏁 CodeAnt Quality Gate ResultsCommit: ✅ Overall Status: PASSEDQuality Gate Details
|
There was a problem hiding this comment.
Security Concern: Overly Permissive Permissions
This PR correctly identifies and fixes the root cause of the apt cache restore failures (permission denied on /var/cache/apt/archives). However, all 7 instances use chmod 777, which grants world-writable permissions.
Issue
chmod 777 is more permissive than necessary. Since actions/cache runs as the runner user, changing ownership to runner:runner with chmod 755 would be sufficient and more secure. The current approach allows any user/process on the runner to modify cached packages, creating a potential attack vector if other workflow steps run untrusted code.
Recommendation
Replace all instances of:
sudo chmod -R 777 /var/cache/apt/archivesWith:
sudo chown -R runner:runner /var/cache/apt/archives && sudo chmod -R 755 /var/cache/apt/archivesThis maintains the fix's effectiveness while following the principle of least privilege.
You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
Included review availability: 0 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 1 review per hour. 📝 WalkthroughWalkthroughThe CI workflows now create the APT archive cache directory and make it writable before cached packages are restored. The setup applies to the CEF learning harness and six CI jobs. ChangesAPT cache setup
Estimated code review effort: 1 (Trivial) | ~5 minutes Merge Risk:🔵 Low · up to The change restores CI package-cache extraction but currently grants world-writable permissions to the archive directory and cached packages, creating a bounded security risk in CI. The PR is mergeable with explicit owner follow-up to use narrower directory and file permissions. Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
… privilege) Real, valid finding from both Amazon Q and Graphite, independently, on all 7 sites: chmod 777 (world-writable) is unnecessarily permissive — it lets any process/user on the runner tamper with cached .deb packages, not just the runner user that actually needs write access. chown runner:runner + chmod 755 grants the same functional access (restore's tar extraction and the save post-hook both run as the runner user; the actual apt-get install steps run as root via sudo, unaffected by ownership since root bypasses permission checks) with tighter scope, matching least-privilege practice even on an ephemeral CI runner. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Uh oh!
There was an error while loading. Please reload this page.
User description
Summary
Real CI evidence from
main's post-#402-mergeBuildjob: the cache restore genuinely found the key (Cache hit for: apt-playwright-chromium-deps-v1) buttarextraction then failed withPermission deniedon every single.debfile, immediately followed byCache not found for input keys—actions/cache's restore step runs as the unprivilegedrunneruser, but/var/cache/apt/archivesis root-owned by default.This means every apt-cache added in #398, across all 7 sites (6 in
ci.yml, 1 incef-learning-harness.yml), has been silently degrading to a full cache miss on every single run since it was introduced — undermining the whole point of that fix, and very plausibly contributing to several of today's apt-mirror-timeout failures that were attributed purely to external Azure-mirror throughput (which is real, but this bug meant the cache was never actually mitigating it as intended).Fix
chmodthe archive directory world-writable (viasudo, matching how the actualapt-get installsteps already needsudo) immediately before each cache-restore step, sotar's unprivileged extraction can actually write into it.Test plan
Cache Size: ~X MBfollowed by no permission errors), not another silent "Cache not found" after a reported hitapt-get installsteps themselves (they already run as root viasudo, unaffected by this)🤖 Generated with Claude Code
Summary by Sourcery
Enable reliable apt package cache restoration across CI workflows.
Bug Fixes:
CI:
CodeAnt-AI Description
Restore apt package caching across CI jobs
What Changed
Impact
✅ Fewer repeated apt package downloads✅ Fewer CI failures caused by apt mirror timeouts✅ Working cache restores instead of silent cache misses💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.
Summary by CodeRabbit