ci(feed): キャッシュのキーは毎回変えて保存しrestore-keysで最新をとるように #207
Conversation
|
Warning Rate limit exceeded@yamadashy has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 16 minutes and 3 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (5)
📝 Walkthrough📝 Walkthrough## Walkthrough
The pull request focuses on modifying the GitHub Actions workflow configurations for CI and feed generation. The primary changes involve updating the caching mechanism for feed images by introducing a custom action located at `./.github/actions/use-feed-cache`. This action simplifies the cache management process by consolidating the previous restore and save steps into a single step, utilizing a dynamically generated cache key. The workflows maintain their overall structure and functionality while enhancing clarity and efficiency in cache handling.
## Changes
| File | Change Summary |
|------|----------------|
| `.github/workflows/ci.yml` | - Replaced steps for restoring and saving feed images cache with a single custom action for cache management. |
| `.github/workflows/generate-feed.yml` | - Updated to use a custom action for feed images cache management, simplifying previous steps. <br> - Clarified cron expression comments regarding execution times. |
| `.github/actions/use-feed-cache/action.yml` | - Introduced a new composite action for restoring and saving feed cache, including dynamic cache key generation and consistent cache path management. |
| `.github/workflows/external-test.yml` | - Added a step to utilize the new feed cache action in the `test-external` job after the `npm ci` command. |
## Possibly related PRs
- **#205**: The changes in this PR involve updating the CI workflow to incorporate caching mechanisms for feed images, which directly relates to the caching mechanism changes in the main PR's CI workflow configuration.
- **#206**: This PR introduces caching for feed and Open Graph data in the `FeedCrawler` class, which aligns with the main PR's focus on enhancing caching mechanisms for feed images in the CI workflow.Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
.github/workflows/generate-feed.yml (1)
Line range hint
4-8: Consider adjusting the cron schedule for better reliabilityThe comment indicates issues with 9 AM (UTC 0) execution. This is a common problem due to high load at midnight UTC. Consider shifting the schedule slightly (e.g., a few minutes offset) to avoid peak times.
Would you like me to help devise a more reliable cron schedule that avoids peak execution times?
.github/workflows/ci.yml (1)
102-122: Cache configuration maintains consistency across workflowsThe cache configuration correctly mirrors the implementation in
generate-feed.yml, ensuring consistent behavior across workflows.Consider extracting the cache configuration into a reusable workflow to:
- Reduce duplication
- Ensure future changes are applied consistently
- Simplify maintenance
Would you like me to demonstrate how to create a reusable workflow for the cache configuration?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/ci.yml(1 hunks).github/workflows/generate-feed.yml(1 hunks)
🔇 Additional comments (2)
.github/workflows/generate-feed.yml (2)
29-39: Well-structured cache configuration with proper fallback strategy
The cache configuration is well-implemented:
- Uses unique cache keys per run with
github.run_id - Implements proper fallback through
restore-keys - Follows recommended patterns from GitHub's documentation
The comment explaining the strategy is helpful for future maintenance.
43-50: Consistent cache save configuration
The cache save configuration correctly mirrors the restore configuration, ensuring proper cache management.
yamadashy
force-pushed
the
chore/cache-key
branch
from
5fdaaaf to
4450921
Compare
yamadashy
force-pushed
the
chore/cache-key
branch
2 times, most recently
from
43f18dc to
09f17d3
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
.github/actions/use-feed-cache/action.yml (2)
14-18: Consider adding hash of dependency files to cache keyWhile using
github.run_idensures unique caches, consider adding a hash of relevant configuration files to the restore-keys for more precise cache restoration. This could help when dependencies or feed configurations change.Example implementation:
- key: ${{ runner.os }}-feed-${{ github.run_id }} - restore-keys: | - ${{ runner.os }}-feed- + key: ${{ runner.os }}-feed-${{ github.run_id }}-${{ hashFiles('package-lock.json', 'feed-config.json') }} + restore-keys: | + ${{ runner.os }}-feed-${{ github.run_id }}- + ${{ runner.os }}-feed-
1-28: Consider implementing cache monitoringWhile the caching strategy is solid, consider adding cache monitoring to track:
- Cache hit rates
- Cache size growth over time
- Cache restore times
This could help optimize the caching strategy further and identify potential issues early.
You could implement this by:
- Adding cache size logging in the action
- Setting up cache usage metrics collection
- Implementing automatic cache cleanup for old entries
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
.github/actions/use-feed-cache/action.yml(1 hunks).github/workflows/ci.yml(1 hunks).github/workflows/external-test.yml(1 hunks).github/workflows/generate-feed.yml(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- .github/workflows/ci.yml
- .github/workflows/generate-feed.yml
🔇 Additional comments (3)
.github/workflows/external-test.yml (1)
26-26: LGTM! Verify cache effectiveness in CI runs
The placement of the cache action is correct - after dependency installation but before test execution. This ensures that the cache is available for the tests while maintaining a clean state after fresh dependencies are installed.
Let's verify the cache effectiveness:
✅ Verification successful
Cache implementation looks correct and well-configured
The cache action is properly implemented with both restore and save operations:
- Uses the official actions/cache v4 with separate restore/save steps
- Caches appropriate paths (.cache and feed-related image directories)
- Implements a rolling cache strategy with unique keys per run
- Saves cache even on failure with
if: always() - Positioned correctly in the workflow after npm install
The implementation follows best practices for GitHub Actions caching, ensuring optimal cache usage for feed-related assets.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check recent workflow runs to verify cache hit rates
gh run list --workflow=external-test.yml --limit 5 --json conclusion,databaseId | \
while read -r run; do
run_id=$(echo "$run" | jq -r '.databaseId')
echo "Checking run $run_id for cache operations..."
gh run view "$run_id" --log | grep -A 2 "Cache hit"
done
Length of output: 744
Script:
#!/bin/bash
# Let's first check if the cache action exists and its implementation
fd "use-feed-cache" .github/actions -x cat {}
# Also check the workflow file to understand the cache configuration
cat .github/workflows/external-test.yml
Length of output: 702
Script:
#!/bin/bash
# Let's check the contents of the use-feed-cache action directory
fd . .github/actions/use-feed-cache -t f -x cat {}
# Also check if there are any other files referencing this cache
rg "use-feed-cache" -g '!.git'
Length of output: 921
.github/actions/use-feed-cache/action.yml (2)
10-13: LGTM! Cache paths are well-defined
The cache paths cover all necessary feed-related assets:
.cachefor temporary datafeed-thumbnailsandfeed-iconsfor image assets
20-28: LGTM! Robust cache save implementation
Good practices observed:
- Using
if: ${{ always() }}ensures cache is saved even on job failure - Consistent paths between restore and save operations
- Using the same key as restore ensures cache coherence
yamadashy
force-pushed
the
chore/cache-key
branch
from
09f17d3 to
43f18dc
Compare
こちらを参考に。
actions/cache#342 (comment)
また、compositeでactionを再利用