-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Repository update fallback to default branch when requested too early #4146
Comments
Make sure you have read the issue guidelines and that you filled out the entire template. If you have an issue identical to this, do not add comments like "same here", "i have this too", instead add a 👍 reaction to the issue description. Thanks! 👍 |
@ludeeus What information is missing? |
I see that there is a fallback to downloading the individual files. I'll try to debug why that does not give us the latest files. |
Debug logs? Diagnostics? |
Here are the debug logs:
In this case It seems that GitHub internally uses a 5 minute cache for raw files, but adding a token parameter would work around it for public repos: |
Another, possibly more reliable solution is to use the commit hash to retrieve the files instead of the branch: This way when HACS tells me that commit X will be downloaded, it will actually download it: |
Yes, when its requested like this it should not try the default branch, that is a part of the old logic. |
Yes, it's not a typical use-case :) By the way, I'm not sure if it's a timing thing or a change from GitHub, but the zipball from yesterday is still missing: I get a 404 from the upstream too, which has not changed in 5 days 🤔 |
Oh! My bad.. |
This URL with the full hash however works: |
System Health details
System Information
Home Assistant Community Store
AccuWeather
Home Assistant Cloud
Home Assistant Supervisor
Dashboards
Recorder
Checklist
Describe the issue
When developing an integration, I often push to GitHub and then download it via HACS. Sometimes the zipball that HACS downloads returns a 404 because it probably takes some time to be available. When this happens, HACS does not display an error. It also prompts me to restart Home Assistant to update the integration, even though it failed to update.
Reproduction steps
Quicklyupdate it via HACSRepeat until the error below is logged as it requires a certain timing.Debug logs
Note that HACS displays and tries to download the correct hash, but in this case it took ~10 minutes for GitHub to catch up and start serving the
zipballcorrect raw file.Diagnostics dump
No response
The text was updated successfully, but these errors were encountered: