Predictable permanent release asset urls

currently the whole release section is nearly unusable in an automated manner.

on github we have clean predictable urls to release assets, which can be easily fetched with wget.

https://github.com/composer/composer/releases

wget https://github.com/composer/composer/releases/download/1.8.6/composer.phar

on gitlab the situation is terrible. i tried to simply attach a file to a release, then i noticed it is just an uploaded file for the text but no asset. currently it is not possible to add an asset via the gui. so i am forced to use the api. but the api cannot handle binary files it only can handle links which requires me to use the uploaded file from my relase content as link target.

the url of the uploaded file from the release content is https://gitlab.com/c33s-group/yaml-convert/uploads/955b8acad6acf786124186ddb47b23e5/yaml-convert.phar

the hash is not helpful at all. it makes the url unpredictable which is a very bad UX. i can't build a script which automactically downloads a known version number.

creating an asset url does not mask with sometthing like https://gitlab.com/c33s-group/yaml-convert/releases/3.0.0/yaml-convert.phar it simply sets the hashed url as url.

https://gitlab.com/c33s-group/yaml-convert/-/releases

wget https://gitlab.com/c33s-group/yaml-convert/uploads/955b8acad6acf786124186ddb47b23e5/yaml-convert.phar

do i get something wrong, missed something in the docs or is the situation with releases that bad on gitlab? i really don't like github any more but i am thinking of mirroring my repo to github to have meaningful binary urls

the following should be in its own issues but i just wanted to mention it here:

Prevent zipping of single file artefacts

the artefact urls are predictable but i can't prevent the ci from creating a zip file. a phar file or a other binary file should be directly downloadable to be easy to use

wget https://github.com/composer/composer/releases/download/1.8.6/composer.phar && php composer.phar install

without to run an unzip command before.

Release from gitlab-ci without private token

i would really like to handle the releases from the ci without the workarounds and the need to provide a private token to the runner to allow to interact with the api. at least there should be a create_release permission for the runner token (only create not update!)

https://gitlab.com/gitlab-org/gitlab-ce/issues/56022

cursor gone after preview

~~just noticed previewing the issue text swallows my cursor. no blinking cursor any more on waterfox~~

edit: created an issue for the cursor problem https://gitlab.com/gitlab-com/support-forum/issues/4766

Edited Sep 10, 2019 by julian