Avatar url#8
Conversation
📝 WalkthroughWalkthroughThis pull request bumps the project version to 1.0.4 across project metadata, CI workflows, and package manager manifests (AUR, Homebrew, Scoop), including updated checksums and vendored Python dependency versions. The avatar cache refresh logic is simplified to unconditionally re-download on staleness rather than comparing URLs. ChangesVersion 1.0.4 Release and Package Manager Updates
Avatar Cache Refresh Simplification
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
hubfetch/cache.py (1)
66-66: ⚡ Quick winReplace the inline profane comment with neutral rationale.
Line 66 uses profanity; please swap it for a short professional note describing why unconditional refresh is intentional.
🤖 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 `@hubfetch/cache.py` at line 66, Replace the profane inline comment "turns out GitHub avatar urls don't change so fuck this shit honestly" in hubfetch/cache.py with a short, neutral rationale explaining that GitHub avatar URLs are stable so an unconditional refresh is intentional (e.g., "GitHub avatar URLs are stable; skip conditional refresh to simplify caching"). Update the comment near the existing avatar/cache logic to briefly state the reason for the unconditional refresh and maintain professional tone.
🤖 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/build.yml:
- Around line 7-12: The workflow defines workflow_dispatch.inputs.version but
the release step (softprops/action-gh-release@v2) doesn't use it, so the action
falls back to github.ref_name; update the release step to pass the user-provided
input as the tag by setting the action input tag_name to the dispatch input (use
github.event.inputs.version), e.g. add tag_name: ${{ github.event.inputs.version
}} (and optionally use the same input for name/release_name) so the created
release uses the chosen version.
In `@contrib/scoop/hubfetch.json`:
- Line 8: The Scoop manifest contains an empty "hash" field which disables
integrity validation; compute the correct SHA256 of the distributed hubfetch.exe
(the released binary referenced by the manifest) and replace the empty string in
the "hash" JSON property with that hex SHA256 value so the manifest's "hash"
entry contains the correct checksum for hubfetch.exe.
In `@hubfetch/cache.py`:
- Around line 67-70: The code updates cache metadata (meta.update and _save_json
with META_FILE) immediately after calling _download_avatar(current_avatar_url,
dest), which means a failed download still marks avatar_last_checked and
suppresses retries; change this so the metadata is only updated when
_download_avatar succeeds: wrap the download call to detect success (either by
its return value or by catching exceptions from _download_avatar), log or handle
the failure without touching meta, and only perform meta.update({"avatar_url":
current_avatar_url, "avatar_last_checked": now}) and _save_json(META_FILE, meta)
when the download completed successfully (referencing _download_avatar,
meta.update, _save_json, META_FILE, avatar_last_checked, current_avatar_url).
---
Nitpick comments:
In `@hubfetch/cache.py`:
- Line 66: Replace the profane inline comment "turns out GitHub avatar urls
don't change so fuck this shit honestly" in hubfetch/cache.py with a short,
neutral rationale explaining that GitHub avatar URLs are stable so an
unconditional refresh is intentional (e.g., "GitHub avatar URLs are stable; skip
conditional refresh to simplify caching"). Update the comment near the existing
avatar/cache logic to briefly state the reason for the unconditional refresh and
maintain professional tone.
🪄 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
Run ID: ec8396da-cb32-41cd-9d7a-90354103e2e6
⛔ Files ignored due to path filters (1)
uv.lockis excluded by!**/*.lock
📒 Files selected for processing (6)
.github/workflows/build.ymlcontrib/aur/PKGBUILDcontrib/homebrew/homebrew.rbcontrib/scoop/hubfetch.jsonhubfetch/cache.pypyproject.toml
| workflow_dispatch: # manual trigger | ||
| inputs: | ||
| version: | ||
| description: 'Version tag' | ||
| required: true | ||
| default: 'v1.0.4' |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
For softprops/action-gh-release@v2, what tag is used by default on workflow_dispatch events, and is tag_name required to force a specific release tag?
💡 Result:
For softprops/action-gh-release@v2, the tag_name input defaults to github.ref_name [1][2][3]. When running via a workflow_dispatch event, github.ref_name corresponds to the branch or tag from which the workflow was triggered, which may not be a valid release tag [1][2][4]. Because the action requires a valid Git tag to create a GitHub Release, it will fail if the default github.ref_name is not a valid tag [4]. Therefore, while tag_name is technically optional in the action's configuration schema, it is effectively required for workflow_dispatch events to ensure the release is associated with a specific, valid tag [4]. To force a specific release tag, you must explicitly provide the desired tag to the tag_name input [3][5][6].
Citations:
- 1: https://github.com/softprops/action-gh-release/tree/refs/tags/v2
- 2: https://github.com/softprops/action-gh-release
- 3: https://github.com/softprops/action-gh-release/blob/master/README.md
- 4: default tag name not work softprops/action-gh-release#270
- 5: https://chromium.googlesource.com/external/github.com/google/error-prone/+/refs/heads/test_671794396/.github/workflows/release.yml
- 6: https://oneuptime.com/blog/post/2025-12-20-workflow-dispatch-inputs-github-actions/view
🏁 Script executed:
#!/bin/bash
set -euo pipefail
file=".github/workflows/build.yml"
if [ ! -f "$file" ]; then
echo "Missing $file" >&2
exit 1
fi
echo "== Top of file =="
sed -n '1,120p' "$file" | nl -ba -w2 -s': '
echo
echo "== Release step context =="
rg -n "Create GitHub Release|action-gh-release|softprops/action-gh-release" "$file" || trueRepository: PranavU-Coder/hubfetch
Length of output: 146
🏁 Script executed:
#!/bin/bash
set -euo pipefail
file=".github/workflows/build.yml"
if [ ! -f "$file" ]; then
echo "Missing $file" >&2
exit 1
fi
echo "== Top of file =="
sed -n '1,120p' "$file" | nl -ba -w2 -s': '
echo
echo "== Release step context =="
rg -n "Create GitHub Release|action-gh-release|softprops/action-gh-release" "$file" || trueRepository: PranavU-Coder/hubfetch
Length of output: 146
🏁 Script executed:
#!/bin/bash
set -euo pipefail
file=".github/workflows/build.yml"
[ -f "$file" ] || { echo "Missing $file" >&2; exit 1; }
echo "== workflow_dispatch block (lines ~1-60) =="
awk 'NR>=1 && NR<=60 {printf "%4d: %s\n", NR, $0}' "$file" | sed -n '1,60p'
echo
echo "== Release step + surrounding lines (search) =="
awk 'NR>=1 && NR<=120 {print NR ":" $0}' "$file" | rg -n "softprops/action-gh-release|Create GitHub Release|with:|tag_name|github\.event\.inputs\.version|workflow_dispatch" -n || trueRepository: PranavU-Coder/hubfetch
Length of output: 1768
🌐 Web query:
softprops/action-gh-release v2 tag_name must exist as git tag workflow_dispatch default github.ref_name branch
💡 Result:
The softprops/action-gh-release action (including v2) does not strictly require the tag_name to exist as a pre-existing Git tag in your repository before the action runs [1][2]. If you do not explicitly provide a tag_name, the action defaults to using github.ref_name [1][2]. When triggered by a workflow_dispatch or other events, github.ref_name will reflect the branch or tag name that triggered the workflow [1][2]. If you want to use this action to create a release based on a specific commit or branch, you can explicitly set the tag_name input [1][2]. Key considerations: 1. Tag Creation: If the tag_name provided does not exist as a Git reference, the action can still create a GitHub Release associated with the provided target_commitish (which defaults to the repository's default branch) [1][2]. 2. Workflow Triggers: When using workflow_dispatch, github.ref_name will typically be the branch from which the workflow was manually triggered. If you manually trigger the workflow on a branch, the action will use that branch name as the release tag_name unless you override it [1][2]. 3. Permissions: Ensure your job has the appropriate permissions (contents: write) to create releases, otherwise you may encounter a 403 error [3]. In summary, while the action is commonly used with Git tags (e.g., via on: push: tags:), it is flexible enough to create releases for arbitrary commit SHAs or branch names by explicitly defining the tag_name input [1][2].
Citations:
- 1: https://github.com/softprops/action-gh-release
- 2: https://github.com/softprops/action-gh-release/blob/master/README.md
- 3: https://stackoverflow.com/questions/76362343/creating-a-release-using-github-action-fails-with-http-403
Use the workflow_dispatch version input for the release tag (tag_name)
.github/workflows/build.yml defines workflow_dispatch.inputs.version, but the “Create GitHub Release” step (softprops/action-gh-release@v2) never uses it; without tag_name, the action uses github.ref_name (typically the branch name for manual dispatch), so the created release tag won’t match the operator’s chosen version.
Proposed fix
- name: Create GitHub Release
uses: softprops/action-gh-release@v2
with:
+ tag_name: ${{ github.event_name == 'workflow_dispatch' && github.event.inputs.version || github.ref_name }}
files: artifacts/*
generate_release_notes: true🤖 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/build.yml around lines 7 - 12, The workflow defines
workflow_dispatch.inputs.version but the release step
(softprops/action-gh-release@v2) doesn't use it, so the action falls back to
github.ref_name; update the release step to pass the user-provided input as the
tag by setting the action input tag_name to the dispatch input (use
github.event.inputs.version), e.g. add tag_name: ${{ github.event.inputs.version
}} (and optionally use the same input for name/release_name) so the created
release uses the chosen version.
There was a problem hiding this comment.
@PranavU-Coder, glad you agree! When you're ready, you can apply the proposed fix to ensure the workflow_dispatch-triggered release uses the operator-supplied version instead of falling back to github.ref_name (the branch name):
- name: Create GitHub Release
uses: softprops/action-gh-release@v2
with:
+ tag_name: ${{ github.event_name == 'workflow_dispatch' && github.event.inputs.version || github.ref_name }}
files: artifacts/*
generate_release_notes: trueThis way, both push-tag and manual dispatch workflows will correctly target the intended release tag.
| _download_avatar(current_avatar_url, dest) | ||
|
|
||
| meta.update({"avatar_url": current_avatar_url, "avatar_last_checked": now}) | ||
| _save_json(META_FILE, meta) |
There was a problem hiding this comment.
Handle avatar download failure before advancing cache metadata.
If _download_avatar fails on Line 67, Lines 69-70 still mark the avatar as freshly checked. That suppresses retries for 6 hours and can leave stale/broken cache state.
Proposed fix
- _download_avatar(current_avatar_url, dest)
-
- meta.update({"avatar_url": current_avatar_url, "avatar_last_checked": now})
- _save_json(META_FILE, meta)
+ if _download_avatar(current_avatar_url, dest):
+ meta.update({"avatar_url": current_avatar_url, "avatar_last_checked": now})
+ _save_json(META_FILE, meta)
+ else:
+ # Keep prior last_checked so next call retries sooner.
+ if not dest.exists():
+ return None🤖 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 `@hubfetch/cache.py` around lines 67 - 70, The code updates cache metadata
(meta.update and _save_json with META_FILE) immediately after calling
_download_avatar(current_avatar_url, dest), which means a failed download still
marks avatar_last_checked and suppresses retries; change this so the metadata is
only updated when _download_avatar succeeds: wrap the download call to detect
success (either by its return value or by catching exceptions from
_download_avatar), log or handle the failure without touching meta, and only
perform meta.update({"avatar_url": current_avatar_url, "avatar_last_checked":
now}) and _save_json(META_FILE, meta) when the download completed successfully
(referencing _download_avatar, meta.update, _save_json, META_FILE,
avatar_last_checked, current_avatar_url).
There was a problem hiding this comment.
@PranavU-Coder, sounds good! When you do, the proposed fix in the comment above should be a straightforward change — just gate the meta.update and _save_json calls on the return value of _download_avatar. Feel free to ping me if you have any questions. 🐇
1 participant
Please describe the changes this PR makes and why it should be merged:
Status and versioning classification:
Summary by CodeRabbit
Bug Fixes
Chores