⚡ Bolt: Optimize build workflow by caching GitHub API responses

[mentalblank]

User description

💡 What: Modified .github/workflows/build.yml to cache GitHub API responses during the update check phase and reuse them during the download phase.
🎯 Why: The original workflow made redundant API calls (fetching releases/latest and assets_url) for every file in every updated repository, increasing latency and API usage.
📊 Impact: Reduces API calls by approximately 66% (from ~120 to ~40) for a full build, significantly reducing latency and avoiding rate limit risks.
🔬 Measurement: Verified with a local reproduction script mocking the API responses.

---

PR created automatically by Jules for task 16405038583129980608 started by @mentalblank

---

PR Type

Enhancement

---

Description

• Cache GitHub API responses to eliminate redundant API calls

• Reduce API calls by ~66% (120 to 40) for full builds

• Store release JSON in files during check phase, reuse in download phase

• Add learning documentation about the optimization

---

Diagram Walkthrough

flowchart LR
  A["Check Phase<br/>fetch_release_info"] -->|"Save response"| B["release_json_*.json<br/>Cache Files"]
  B -->|"Read cached data"| C["Download Phase<br/>handle_downloads"]
  C -->|"Extract assets"| D["Process Downloads"]
  E["Before: 2 API calls<br/>per file"] -.->|"Optimized to"| F["After: 1 API call<br/>per repo"]

Loading

File Walkthrough

	Relevant files
Enhancement	build.yml Cache GitHub API responses to eliminate redundant calls    .github/workflows/build.yml Added caching of GitHub API release responses in fetch_release_info() by saving JSON to release_json_*.json files Modified handle_downloads() to read cached release JSON instead of making redundant API calls Removed two redundant curl calls that fetched releases/latest and assets_url for each file Updated cleanup commands to remove cached JSON files after download phase completes +10/-3
Documentation	bolt.md Document API caching optimization learning                              .jules/bolt.md Added new learning documentation file capturing the optimization insight Documents the problem of redundant API calls in CI/CD workflows Records the solution of caching and reusing API responses +3/-0

---

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
🔴	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Missing failure checks: The workflow writes and later reads cached GitHub API JSON without verifying curl success, JSON validity, or cache file existence, which can cause silent/unclear failures when the API rate-limits or returns errors. Referred Code response=$(curl -s -H "Authorization: token $GITHUB_TOKEN" "https://api.github.com/repos/$repo/releases/latest") echo "$response" > "release_json_${safe_repo}.json" local tag=$(echo "$response" | jq -r ".tag_name // empty") if [ -n "$tag" ]; then echo "$repo|$tag" > "release_info_${safe_repo}.txt" else echo "Error: Unable to find the latest release for $repo." fi } handle_downloads() { local repo=$1 local safe_repo=${repo//\//_} local files=$(echo "$DOWNLOAD_FILES" | jq -r ".repos[\"$repo\"].files // empty") if [ -n "$files" ]; then local assets=$(cat "release_json_${safe_repo}.json" | jq -c '.assets') if [ -z "$assets" ] || [ "$assets" == "null" ]; then echo "Error: No assets found in cached response for $repo" return fi Learn more about managing compliance generic rules or creating your own custom rules
⚪	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Cache file trust: The workflow consumes release_json_${safe_repo}.json as trusted input without validating its schema/content beyond a null check, so reviewers should confirm the workspace cannot be poisoned between phases and that failure modes are acceptable. Referred Code local safe_repo=${repo//\//_} local files=$(echo "$DOWNLOAD_FILES" | jq -r ".repos[\"$repo\"].files // empty") if [ -n "$files" ]; then local assets=$(cat "release_json_${safe_repo}.json" | jq -c '.assets') if [ -z "$assets" ] || [ "$assets" == "null" ]; then echo "Error: No assets found in cached response for $repo" return fi Learn more about managing compliance generic rules or creating your own custom rules

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Prevent writing invalid cache files To prevent creating invalid cache files from failed API calls, move the command that writes the response to the cache file inside the conditional block that verifies a valid tag_name was found. .github/workflows/build.yml [129-136] response=$(curl -s -H "Authorization: token $GITHUB_TOKEN" "https://api.github.com/repos/$repo/releases/latest") -echo "$response" > "release_json_${safe_repo}.json" local tag=$(echo "$response" | jq -r ".tag_name // empty") if [ -n "$tag" ]; then + echo "$response" > "release_json_${safe_repo}.json" echo "$repo|$tag" > "release_info_${safe_repo}.txt" else echo "Error: Unable to find the latest release for $repo." fi Apply / Chat Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies that a failed curl command could lead to a corrupted cache file, and proposes moving the caching logic to only execute after successfully parsing a tag_name, which significantly improves the script's robustness.	Medium
	Verify cache file exists Before attempting to read the cached JSON file, add a check to verify that the file exists and is not empty to prevent potential errors. .github/workflows/build.yml [145] -local assets=$(cat "release_json_${safe_repo}.json" | jq -c '.assets') +if [ ! -s "release_json_${safe_repo}.json" ]; then + echo "Error: Cache file missing for $repo" + return 1 +fi +local assets=$(jq -c '.assets' "release_json_${safe_repo}.json") Apply / Chat Suggestion importance[1-10]: 6 __ Why: This suggestion correctly points out that the script could fail if the cache file is missing or empty. Adding a check with [ ! -s "..." ] is a simple and effective way to improve the script's robustness against this potential issue.	Low
General	Use POSIX string comparison For better POSIX compatibility, replace the == operator with = for the string comparison within the if statement's single brackets. .github/workflows/build.yml [146] -if [ -z "$assets" ] || [ "$assets" == "null" ]; then +if [ -z "$assets" ] || [ "$assets" = "null" ]; then Apply / Chat Suggestion importance[1-10]: 3 __ Why: The suggestion correctly recommends using the POSIX-compliant = for string comparison instead of == inside [ ], which improves script portability, although the current bash context makes this a minor style and compatibility improvement.	Low
Security	Make file cleanup command safer To prevent unintended file deletion from wildcard expansion, disable globbing using set -f before the rm command and re-enable it with set +f afterward. .github/workflows/build.yml [205] +set -f # disable globbing rm -f release_info_*.txt release_json_*.json +set +f # re-enable globbing Apply / Chat Suggestion importance[1-10]: 2 __ Why: While the suggestion to disable globbing with set -f is a valid shell scripting safety practice, the risk in this specific context is very low as the command uses a static string pattern, making the change a minor improvement.	Low
More