AppImage
Download button for gitlab.com Releases
If we have an URL in data that looks like this:
https://gitlab.com/cipres/gemgemgem/-/releases/continuous-devel/downloads/Gemalaya-latest-x86_64.AppImage
Then we should use
https://gitlab.com/cipres/gemgemgem/-/releases/
as the URL for the Download button.
References:
- https://github.com/AppImage/appimage.github.io/issues/3211
- https://github.com/AppImage/appimage.github.io/pull/3248
@probonopd I'd be happy to help on this, i've seen where this must be changed, mainly code/worker.sh ?
Everything happens in code/worker.sh. But to be more precise, this is how we are doing it for GitHub Releases and for openSUSE Build Service (OBS):
https://github.com/AppImage/appimage.github.io/blob/438806f5be851be2cb0c27f486eae2d788208ce2/code/worker.sh#L498-L511
Wow that thing is wild. Two questions:
-
what is the purpose of the [[ "${URL}" != "download" ]] second-part of the if check (line 21) ? It seemed specific to github so i removed that for GL
-
why is GH_USER redefined here, when the same work had already been done here with GHUSER ? Is this historical, or related to variable scope ?
I'll make a PR soon so that you can comment on it. Thanks.
This script has "organically grown" over the years and it's been a while...
- https://github.com/AppImage/appimage.github.io/commit/f3c0414cba087227d2b6d74ad6ec5295d378e6d5 says "do not redirect direct links"; iirc this is so that we can use deep links to downloads on GitHub Releases as input for running the test (in addition to just using the URL with the user name and repo name, which results in guesstimating the AppImage file download URL); don't worry about this for GitLab for now
- About GH_USER I don't remember; might be extraneuous
Ok. Here's a first version. The URL parsing works, the rest i don't know but i don't see why it wouldn't.
It sets type as GitLab in the links section, there must be another place in the codebase (website generation) that would need to be changed i suppose.
Shouldn't we check whether GLURL contains the AppImage download URL given in data/..., or something like that? I don't think every GitLab project necessarily has the AppImage on GLURL
It sets type as GitLab in the links section, there must be another place in the codebase (website generation) that would need to be changed i suppose.
From a quick look it doesn't seem to be the case; we are currently not using that information (altough we could e.g., show GitHub/GitLab/... icons on the buttons).
Shouldn't we check whether GLURL contains the AppImage download URL given in
data/..., or something like that? I don't think every GitLab project necessarily has the AppImage on GLURL
GLURL equals to the releases root URL (https://gitlab.com/cipres/gemgemgem/-/releases/ for example). Not sure what you mean by "contains", contains like "string contains", or like "in the releases page (GLURL) there's a release which has an asset with that appimage download URL" ?
Whatever works best to prevent us from linking to .../releases pages that don't contain an AppImage.
Whatever works best to prevent us from linking to .../releases pages that don't contain an AppImage.
What needs to be done i think, is to run a regexp on the input URL (from the data file), to check if it has a URL pattern that matches the typical URL format of a gitlab release asset:
https://gitlab.com/user/project/-/releases/tag/downloads/asset-filename
However there's also this type of URL, which is bound to the project ID:
https://gitlab.com/api/v4/projects/4207231/packages/generic/graphviz-releases/8.1.0/graphviz-8.1.0.tar.xz
We need to cover both cases.