Permalink
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
...
- 3 commits
- 4 files changed
- 2 contributors
Commits on Feb 24, 2026
-
Check HTTP status code in vhttpget before returning response body
The vhttpget HTTP client, used by all httpJsonPath-based version providers (GitHub releases, GitHub tags, custom HTTP sources), was returning the response body without checking the HTTP status code. When an API returned a non-2xx response such as 403 for rate limiting or 401 for missing authentication, the error JSON body (e.g. {"message":"API rate limit exceeded"}) flowed into the YAML unmarshaller and jsonpath extraction in tracker.go, which then failed with cryptic error messages containing the raw JSON error object. The fix checks the status code immediately after the HTTP request. For non-2xx responses, it reads up to 512 bytes of the response body and returns a clear error like "GET <url>: 403 Forbidden: API rate limit exceeded" instead of letting the error JSON propagate as valid data. An alternative was adding the status check at the releasesFromHttpJsonPath level in tracker.go, but that would require changing the vhttpget.Getter interface to also return status codes and would leave other callers unprotected. Fixing at the HTTP layer is more robust. Co-Authored-By: Claude Opus 4.6 <[email protected]> -
Avoid dumping raw API response objects into error messages
When jsonpath extraction or map key casting fails on data fetched from GitHub or Docker APIs, several error formatting sites in tracker.go and maputil.go embedded the entire parsed response object via %v. This produced error messages containing thousands of characters of nested maps and arrays, making it nearly impossible to understand what went wrong. The fix introduces a summarizeValue helper that produces concise descriptions of collection types (e.g. "[]interface{} (25 items)" or "map[string]interface{} (keys: [tag_name, name, ...])") instead of dumping full contents. Scalar values are still shown directly, truncated at 200 characters. This preserves enough context for debugging while keeping error output readable. The same approach is applied in maputil.go where raw map contents were also being included in error strings. An alternative was a generic truncate helper that caps %v output at N characters, but type-and-length summaries are more informative for diagnosing structural mismatches than a cut-off dump. Also fixes a typo ("unalble" to "unable") in one of the affected error messages. Co-Authored-By: Claude Opus 4.6 <[email protected]> -
Check HTTP status code in githubreleaseasset getFile before writing t…
…o disk The getFile function downloads a GitHub release asset to a local file. It was not checking the HTTP status code before copying the response body to disk, so a non-2xx response (404 for missing asset, 401 for auth failure) would silently write the JSON error body as the file content. The sibling functions getReleaseByTag and getAssetsByReleaseID in the same file already had proper status checks, making this an inconsistency. The fix adds a status code check consistent with the other functions in the file. It also replaces log.Fatal(err) with return err for the request construction error, since log.Fatal calls os.Exit(1) which bypasses all deferred cleanup and error handling up the call stack. An alternative was reading the error response body and including it in the error message, but for a binary asset download endpoint the error body format varies, so a status code and URL is sufficient and consistent with the pattern used by the other functions. Co-Authored-By: Claude Opus 4.6 <[email protected]>
Loading
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff v0.25.2...master