-
Notifications
You must be signed in to change notification settings - Fork 57
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
Cannot update AppImages hosted on GitLab CI #94
Comments
How can one turn on curl debugging output in Edit: |
In the case of GitLab,
redirects to the latest build (the number may have increased since I posted this) at
The real AppImage is available in the same un-redirected location:
which also gets redirected to the same directory (the number may have increased since I posted this)
So it looks good to me, I suspect there must be a bug in zsync2 and/or AppImageUpdate that gets confused. |
Similar issue: antony-jr/AppImageUpdater#11 |
Ping @TheAssassin. Would be great if you could look into it. Thanks! |
This is caused by https://github.com/AppImage/zsync2/blob/293d65d2683cca8d579efd97a0e31634b21956ca/src/zsclient.cpp#L321-L323. I think it should be save to store the original URL as "referer", and resolve relative links from there. |
Commenting out the line doesn't seem to make a difference, but actually I can update the QtQuick AppImage from GitLab just fine as is. I stepped into the relevant functions, and the |
So it is working for you using the continuous build? I'll need to test again then... |
@probonopd I tested a locally built version. I will test with the released AppImage later. |
Definitely not working for me with today's latest continous build. Tested on Xubuntu 18.04:
|
At a first glance, it looks like GitLab don't support partial responses... I will have to test it a bit myself with curl, I guess. |
Check this out:
AppImageUpdate tries to fetch only the first few bytes of the zsync file when checking for updates to not have to download it entirely, as it only needs the header for this. Therefore and also for the later update process, it requires Partial Content support from the webservers. GitLab doesn't support this at all, so we can't use it with AppImageUpdate. This is out of scope of AppImageUpdate. |
Uh. Thanks for finding this out. I will open a feature request with them. |
So, as we found out today, there's two issues here. One is that the Now, this problem can be fixed easily, and so we did. The issue now is however that GitLab lacks support for partial responses, making binary delta updates impossible (or at least very much less inefficient, the client could read until the chunk it wants is received, and terminate the connection afterwards, but that's far from ideal). So, not really an option. To fix the first part, we should make sure that when the The second part however is completely out of our scope, and we can't fix it, we could only implement some dirty hacks, accepting some major inefficiency. Therefore, we should start to accept 200 responses but instead rather have GitLab implement partial response support. See https://gitlab.com/gitlab-com/support-forum/issues/3655. |
As a workaround, one might want to upload to GitLab Pages as that seems to support the required HTTP Range Requests:
|
Bintray also broke partial requests, see AppImageCommunity/zsync2#5 (comment). This is so annoying... |
As another workaround, one might want to use https://raw.githack.com/ which uses https://www.cloudflare.com/. Works!
|
Isn't that something people should just put in as update information then? |
Yes, I'm just thinking about how. In my Scribus example, |
Prominent AppImage users like Inkscape and Scribus are on GitLab CI, so getting this to work would be really beneficial. |
You need a special transport type I guess, so magic strings are . But that shouldn't be called "GitLab" simply then. This is clearly a baaaaaaad hack around their inability to provide a feature that will save them money. |
Actually there are two separate issues:
I think if we would implement a Transport mechanism to work around 1, then nothing special would be needed to also support 2 if implemented correctly, the user would just put a githack.com URL instead of a gitlab.com URL into the update information. I have opened a ticket on 1, https://gitlab.com/gitlab-com/support-forum/issues/4570. |
1 is actually solved, https://gitlab.com/gitlab-com/support-forum/issues/4570 |
Then maybe raise awareness for 2 with those projects you mentioned and try to get it solved that way. Untrusted third party services are really really annoying. They should not be used in general, and especially not without the consent of the the owner of the project. |
Semi-related, also opened
|
I suspect it has to do with the fact that there is a HTTP argument (
?=...
) involved?The text was updated successfully, but these errors were encountered: