feature: cache installed dependancies to speed up build time#11
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
📝 WalkthroughWalkthroughBoth CI workflows switch from caching pip's download cache to caching the full ChangesCI Virtual Environment Caching
Runtime Dependency Addition
Sequence Diagram(s)(Skipped — changes are CI/config and a single dependency addition; no new multi-component runtime control flow introduced.) Estimated Code Review Effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
.github/workflows/docker-publish.yml (1)
23-23: ⚡ Quick winAlign pip caching strategy with install flags.
Line 23 enables pip cache, but Line 40 disables it via
--no-cache-dir. Keeping both reduces the speed benefit on cache misses.Suggested patch (keep pip cache enabled)
- pip install --no-cache-dir ".[dev]" + pip install ".[dev]"Also applies to: 40-40
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/docker-publish.yml at line 23, The workflow enables pip caching via "cache: 'pip'" but the install step passes "--no-cache-dir", which negates the cache; update the install step used in the workflow (remove the "--no-cache-dir" flag from the pip install command) so pip can use the configured cache, or if you prefer disabling caching keep the "--no-cache-dir" flag and remove/disable "cache: 'pip'"; adjust the pip install invocation and the "cache: 'pip'" setting so they are consistent..github/workflows/ci.yml (1)
28-28: ⚡ Quick winRemove the pip-cache contradiction in install step.
Line 28 enables pip cache, but Line 45 disables pip cache usage with
--no-cache-dir, which undercuts the intended speedup path on misses.Suggested patch
- pip install --no-cache-dir ".[dev]" + pip install ".[dev]"Also applies to: 45-45
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/ci.yml at line 28, The workflow sets cache: 'pip' but the install step passes --no-cache-dir, which negates caching; update the install step to remove the --no-cache-dir flag (or alternatively remove/adjust the cache: 'pip' entry) so pip can use the cache on misses—look for the pipeline step that declares cache: 'pip' and the install command that includes "--no-cache-dir" and make them consistent by deleting the flag or disabling the cache entry.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/ci.yml:
- Around line 25-37: The cache key uses a hardcoded "py3.14" which can restore
an incompatible virtualenv; add id: setup-python to the actions/setup-python@v5
step and update the cache key and restore-keys to reference the actual installed
version via steps.setup-python.outputs.python-version (e.g. replace "py3.14"
with something like "py-${{ steps.setup-python.outputs.python-version }}-venv")
so the .venv cache is version-specific and automatically follows the configured
Python install.
In @.github/workflows/docker-publish.yml:
- Around line 20-33: The cache key hardcodes "py3.14" and allows partial
restores which can mismatch the actual interpreter; update the
actions/setup-python@v5 step by adding id: setup-python (or ensure it already
has that id) so you can reference the real installed interpreter via
steps.setup-python.outputs.python-version, then replace the literal "py3.14" in
the cache key and restore-keys with a dynamic value like ${{ runner.os }}-py${{
steps.setup-python.outputs.python-version }}-venv-${{
hashFiles('pyproject.toml') }} (and tighten or remove loose restore-keys to
avoid partial restores); apply the identical change to the CI workflow (ci.yml)
where the same cache key pattern is used.
---
Nitpick comments:
In @.github/workflows/ci.yml:
- Line 28: The workflow sets cache: 'pip' but the install step passes
--no-cache-dir, which negates caching; update the install step to remove the
--no-cache-dir flag (or alternatively remove/adjust the cache: 'pip' entry) so
pip can use the cache on misses—look for the pipeline step that declares cache:
'pip' and the install command that includes "--no-cache-dir" and make them
consistent by deleting the flag or disabling the cache entry.
In @.github/workflows/docker-publish.yml:
- Line 23: The workflow enables pip caching via "cache: 'pip'" but the install
step passes "--no-cache-dir", which negates the cache; update the install step
used in the workflow (remove the "--no-cache-dir" flag from the pip install
command) so pip can use the configured cache, or if you prefer disabling caching
keep the "--no-cache-dir" flag and remove/disable "cache: 'pip'"; adjust the pip
install invocation and the "cache: 'pip'" setting so they are consistent.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 7608d30d-58b4-4735-9db3-9631f27df30e
📒 Files selected for processing (2)
.github/workflows/ci.yml.github/workflows/docker-publish.yml
| uses: actions/setup-python@v5 | ||
| with: | ||
| python-version: "3.14" | ||
| cache: 'pip' | ||
|
|
||
| - name: Cache pip dependencies | ||
| - name: Cache full virtual environment | ||
| uses: actions/cache@v4 | ||
| id: pip-cache | ||
| id: cache-venv | ||
| with: | ||
| path: ~/.cache/pip | ||
| key: ${{ runner.os }}-pip-${{ hashFiles('pyproject.toml', 'requirements*.txt') }} | ||
| path: .venv | ||
| key: ${{ runner.os }}-py3.14-venv-${{ hashFiles('pyproject.toml') }} | ||
| restore-keys: | | ||
| ${{ runner.os }}-pip- | ||
| ${{ runner.os }}-py3.14-venv- |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/ci.yml | sed -n '20,42p'Repository: varit05/Streaming-Video-RAG
Length of output: 859
🏁 Script executed:
cat -n .github/workflows/ci.yml | sed -n '39,50p'Repository: varit05/Streaming-Video-RAG
Length of output: 560
🌐 Web query:
actions/setup-python@v5 outputs python-version
💡 Result:
The actions/setup-python@v5 action provides a python-version output that returns the precise installed Python (or PyPy/GraalPy) version as a string, particularly useful when the python-version input is a range (e.g., "3.9.0 - 3.12.0" resolves to e.g. "3.12.0") [1][2]. Other outputs include python-path (absolute path to the executable) and cache-hit (boolean for cache restoration) [1][2]. Example usage: - uses: actions/setup-python@v5 id: python-setup with: python-version: '3.x' - run: echo "Python version: ${{ steps.python-setup.outputs.python-version }}" This echoes the exact version installed, such as "3.12.3" [1].
Citations:
- 1: https://github.com/actions/setup-python/blob/main/docs/advanced-usage.md
- 2: https://github.com/actions/setup-python/blob/main/action.yml
Use dynamic Python version in .venv cache key to prevent incompatible virtualenv restoration.
On lines 35 and 37, the hardcoded py3.14 in the cache key and restore-keys fallback creates a maintenance burden and can restore incompatible virtualenv caches if the Python version changes. Use steps.setup-python.outputs.python-version instead, which is provided by actions/setup-python@v5 and contains the exact installed version.
Additionally, adding id: setup-python to the setup-python step (line 25) is required to access its outputs.
Suggested patch
- name: Set up Python
uses: actions/setup-python@v5
+ id: setup-python
with:
python-version: "3.14"
cache: 'pip'
@@
- name: Cache full virtual environment
uses: actions/cache@v4
id: cache-venv
with:
path: .venv
- key: ${{ runner.os }}-py3.14-venv-${{ hashFiles('pyproject.toml') }}
+ key: ${{ runner.os }}-py${{ steps.setup-python.outputs.python-version }}-venv-${{ hashFiles('pyproject.toml') }}
restore-keys: |
- ${{ runner.os }}-py3.14-venv-
+ ${{ runner.os }}-py${{ steps.setup-python.outputs.python-version }}-venv-🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/ci.yml around lines 25 - 37, The cache key uses a
hardcoded "py3.14" which can restore an incompatible virtualenv; add id:
setup-python to the actions/setup-python@v5 step and update the cache key and
restore-keys to reference the actual installed version via
steps.setup-python.outputs.python-version (e.g. replace "py3.14" with something
like "py-${{ steps.setup-python.outputs.python-version }}-venv") so the .venv
cache is version-specific and automatically follows the configured Python
install.
| uses: actions/setup-python@v5 | ||
| with: | ||
| python-version: "3.14" | ||
| cache: 'pip' | ||
|
|
||
| - name: Cache pip dependencies | ||
| - name: Cache full virtual environment | ||
| uses: actions/cache@v4 | ||
| id: cache-venv | ||
| with: | ||
| path: ~/.cache/pip | ||
| key: ${{ runner.os }}-pip-${{ hashFiles('pyproject.toml', 'requirements*.txt') }} | ||
| path: .venv | ||
| key: ${{ runner.os }}-py3.14-venv-${{ hashFiles('pyproject.toml') }} | ||
| restore-keys: | | ||
| ${{ runner.os }}-pip- | ||
| ${{ runner.os }}-py3.14-venv- | ||
|
|
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, check if the file exists and examine lines 20-33
if [ -f .github/workflows/docker-publish.yml ]; then
echo "=== docker-publish.yml lines 20-33 ==="
sed -n '20,33p' .github/workflows/docker-publish.yml
echo ""
echo "=== Full file for context ==="
cat -n .github/workflows/docker-publish.yml
else
echo "File not found: .github/workflows/docker-publish.yml"
fiRepository: varit05/Streaming-Video-RAG
Length of output: 3787
🏁 Script executed:
# Check if ci.yml exists and has similar caching patterns
if [ -f .github/workflows/ci.yml ]; then
echo "=== Searching for cache patterns in ci.yml ==="
grep -n "cache.*py3\|restore-keys\|.venv" .github/workflows/ci.yml || echo "No matches found"
else
echo "ci.yml not found"
fiRepository: varit05/Streaming-Video-RAG
Length of output: 525
🌐 Web query:
actions/setup-python v5 outputs python-version
💡 Result:
The actions/setup-python action (including v5) exposes an output named python-version. You can read it in a workflow like this: steps: - uses: actions/setup-python@v5 id: setup with: python-version: "3.9.0 - 3.12.0" - run: echo ${{ steps.setup.outputs.python-version }} The output is defined as “The installed Python or PyPy version. Useful when given a version range as input.” [1][2] Related outputs you may also see are python-path (absolute path to the Python/PyPy executable) and cache-hit (boolean). [1][2]
Citations:
- 1: https://github.com/actions/setup-python/blob/main/action.yml
- 2: https://github.com/actions/setup-python/blob/main/docs/advanced-usage.md
Harden .venv cache key to use exact interpreter version; avoid partial virtualenv restores.
The cache key on line 30 hardcodes py3.14 as a literal string, and the restore-keys on lines 31–32 allows partial restoration. If the runner's Python patch version changes (e.g., 3.14.0 → 3.14.1), a partially restored .venv may contain packages/bytecode compiled for an incompatible interpreter, causing flaky CI failures.
Use the dynamic python-version output from actions/setup-python@v5 instead. Add id: setup-python to the setup step and reference ${{ steps.setup-python.outputs.python-version }} in the cache key. This ensures the cache key updates automatically when the actual installed Python version changes and prevents partial mismatches.
The same issue exists in .github/workflows/ci.yml (lines 35–37) and requires the same fix.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/docker-publish.yml around lines 20 - 33, The cache key
hardcodes "py3.14" and allows partial restores which can mismatch the actual
interpreter; update the actions/setup-python@v5 step by adding id: setup-python
(or ensure it already has that id) so you can reference the real installed
interpreter via steps.setup-python.outputs.python-version, then replace the
literal "py3.14" in the cache key and restore-keys with a dynamic value like ${{
runner.os }}-py${{ steps.setup-python.outputs.python-version }}-venv-${{
hashFiles('pyproject.toml') }} (and tighten or remove loose restore-keys to
avoid partial restores); apply the identical change to the CI workflow (ci.yml)
where the same cache key pattern is used.
1 participant
✅ GitHub Actions dependencies cache has been fully optimized.
Changes Implemented:
Both
ci.ymlanddocker-publish.ymlworkflows have been updated with maximum possible caching:✅ Key Optimizations:
setup-pythonpip cache + full venv cache working together--no-cache-dirto avoid storing duplicate files⏱️ Expected Performance Improvements:
This will reliably reduce your 2 minute dependency installation step down to less than 5 seconds for 90% of runs.
The cache will automatically invalidate only when
pyproject.tomlactually changes. All subsequent runs will use the cached environment.Summary by CodeRabbit