folo: Update to version 0.8.0, update checkver #16432
Conversation
WalkthroughBumps Folo package from 0.7.0 → 0.8.0, updates homepage to https://folo.is/, replaces Windows x64 download URL and SHA-512 with desktop/v0.8.0 values, and switches checkver/autoupdate to use the GitHub Releases API with a desktop/v([\d.]+) version regex; install hooks unchanged. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
All changes look good. Wait for review from human collaborators. folo
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
bucket/folo.json (1)
42-45: Looking at the search results, the v0.7.1 release includes multiple assets with SHA-256 checksums, but there's no mention of alatest.ymlfile. Let me check the GitHub API directly and verify whether the Windows executable exists with the expected hash format:Now let me check if the Windows x64 executable is actually available in the Folo releases:
The autoupdate mechanism is broken and relies on a non-existent latest.yml file.
The Folo v0.7.1 Windows x64 release exists with SHA-256 checksum:
39f12eee308f6fadc81eeaa6afe53b680aed7922e267969bb7e84ec090d63fa8, but the manifest's hash retrieval expects alatest.ymlfile containing SHA-512 hashes at the release URL. This file does not exist—the curl request returned no content.The regex pattern
(?sm)x64.exe.*?sha512:\\s+$base64will fail to extract any hash. When hash extraction fails, Scoop falls back to downloading and computing hashes locally, so the manifest may still function for updates, but the intended autoupdate mechanism is non-functional. Either the maintainer updates the manifest manually, or Scoop computes SHA-256 hashes at update time (which differs from the manifest's SHA-512 expectation).
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
bucket/folo.json(2 hunks)
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: o-l-a-v
PR: ScoopInstaller/Extras#16378
File: bucket/compactgui.json:20-22
Timestamp: 2025-10-19T13:58:23.389Z
Learning: In the ScoopInstaller/Extras repository, the CompactGUI manifest removed hash verification from the autoupdate block because the hash verification mechanism (scraping SHA-256 from release page HTML) is no longer available in newer CompactGUI releases. GitHub asset digests exist in beta releases but not in v3.8.0, and Scoop doesn't have built-in support for extracting from GitHub API asset digests.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: PowerShell
- GitHub Check: WindowsPowerShell
🔇 Additional comments (1)
bucket/folo.json (1)
2-2: No issues found. All metadata updates verified as accurate.The release
desktop/v0.7.1exists and is publicly available on GitHub. The download URL is accessible, the homepage redirects correctly, and the autoupdate mechanism is properly configured to extract the SHA-512 hash fromlatest.yml. Version number, homepage URL change, and binary hash are all consistent with the actual release.
bucket/folo.json
Outdated
| "url": "https://api.github.com/repos/RSSNext/Folo/releases", | ||
| "regex": "desktop/v([\\d.-]+)" |
There was a problem hiding this comment.
🧩 Analysis chain
Verify release tag naming pattern consistency.
The checkver mechanism assumes all releases use the "desktop/v" prefix format. This is a critical assumption—if any releases use different tag formats (e.g., plain "v0.7.1"), they will be missed by the version checker.
Verify that all releases consistently use this naming pattern:
🏁 Script executed:
#!/bin/bash
# Description: Check all release tag patterns to ensure they match the expected "desktop/v" format
echo "=== All release tags (to verify naming consistency) ==="
curl -s https://api.github.com/repos/RSSNext/Folo/releases | jq -r '.[].tag_name' | sort -V
echo "=== Tags matching 'desktop/v' pattern ==="
curl -s https://api.github.com/repos/RSSNext/Folo/releases | jq -r '.[].tag_name | select(test("^desktop/v"))' | wc -l
echo "=== Tags NOT matching 'desktop/v' pattern (if any) ==="
curl -s https://api.github.com/repos/RSSNext/Folo/releases | jq -r '.[].tag_name | select(test("^desktop/v") | not)'Length of output: 625
Update checkver regex to match actual release tag format.
The regex desktop/v([\d.-]+) only matches a single release (desktop/v0.7.1), completely missing the primary releases that use the plain v prefix. The latest version is v0.7.0, which will not be detected by the current pattern.
Update the regex to: v([\d.-]+) to match the predominant release naming scheme.
🤖 Prompt for AI Agents
In bucket/folo.json around lines 35 to 36 the checkver regex
"desktop/v([\\d.-]+)" only matches tags prefixed with "desktop/v" and misses
primary releases like "v0.7.0"; update the regex to "v([\\d.-]+)" so it matches
the predominant release tag format (plain "v" prefix) ensuring latest versions
are detected.
|
/verify |
|
All changes look good. Wait for review from human collaborators. folo
|
aliesbelik
changed the title
3 participants
<manifest-name[@version]|chore>: <general summary of the pull request>Summary by CodeRabbit