Repository navigation
fix: use commits behind for git repo updates - #2022
pedrolamas merged 2 commits into
Conversation
Moonraker's git_repo versions come from `git describe`, which SemVer misorders for prerelease tags (`1.4.2-beta-4-53` < `1.4.2-beta-4-6`), so repos behind their remote were shown as up-to-date. Fixes fluidd-core#2021 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Pedro Lamas <pedrolamas@gmail.com>
Bundle size report (gzip)
120 chunks compared, 23 changed. Sizes are gzip, matching what nginx serves. |
There was a problem hiding this comment.
Note
Copilot was unable to complete this review at the selected tier due to model policy or plan restrictions.
🟢 Approval recommended
The change is narrowly scoped to git_repo update detection by switching to the backend-provided commits_behind_count while preserving existing behavior for other updater types, with only a moderate follow-up note about null-safe gating.
No open issues 🎉
What changed in this PR
This pull request fixes update detection for Moonraker git_repo updaters by using the backend-provided “commits behind” count instead of SemVer-comparing git describe-derived version strings, which can sort prerelease commit-count suffixes incorrectly and mask available updates.
Changes:
- Update
hasUpdatelogic forgit_repoentries to rely oncommits_behind_count > 0. - Preserve existing update detection behavior for other updater types (package counts, SemVer comparison, and hash fallback).
Outstanding review note (moderate): The current check uses 'commits_behind_count' in versionInfo, which may short-circuit SemVer/hash checks even if the value is null/undefined or appears for a non-git_repo updater in the future; gate the logic explicitly on configured_type === 'git_repo' and treat the count as null-safe.
This pull request requires changes.
| File | Summary |
|---|---|
src/store/version/getters.ts |
Adjusts hasUpdate for Moonraker git_repo updaters to use commits_behind_count rather than SemVer comparisons of git describe version strings. |
Review effort: Balanced
pedrolamas
left a comment
pedrolamas
left a comment
There was a problem hiding this comment.
🤖 AI Code Review — 2 finding(s) across 1 file(s)
Switching git_repo off SemVer is the right fix for #2021. Only GitRepo carries commits_behind_count, so system packages, web/zip, and python updaters keep the existing comparison. The new predicate is wider than Moonraker's own "is current" check, and the getter has no regression test.
On stable/beta channels Moonraker can leave commits_behind_count set after resetting remote_hash to current_hash, in which case an update is a no-op. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Pedro Lamas <pedrolamas@gmail.com>
Moonraker's
git_repoversions come fromgit describe(<tag>-<commit count>), which SemVer misorders for prerelease tags:1.4.2-beta-4-53sorts before1.4.2-beta-4-6, so a repo behind its remote was shown as up-to-date.hasUpdatenow treats a git repo as outdated whencurrent_hash !== remote_hash(Moonraker's ownis_current()check) andcommits_behind_count > 0. The count alone isn't enough: on stable/beta, Moonraker can resetremote_hashtocurrent_hashwhile leaving the count set, making an update a no-op. Other updater types keep the SemVer comparison.Fixes #2021
🤖 Generated with Claude Code