Attachment links are not human readable again

[xoxys]

• Gitea version (or commit ref): 1.11.4
• Operating system: CentOS 7
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite

Description

After upgrading to v1.11.3 release attachment links are not human-readable again and now looks like https://gitea.example/attachments/a0023262-7abf-461d-9271-2e9f195ecebc instead of https://gitea.example/xoxys/cups-rpm/releases/download/v.1.0.0.

[jolheiser]

The change was in #9529 and this functionality can return once #9534 is fixed.

Until then, the URL pattern still works, it's just no longer exposed on the UI. 🙁

e.g.
https://try.gitea.io/jolheiser/ciw/releases
https://try.gitea.io/jolheiser/ciw/releases/download/test2/simplog.png

[6543]

@xoxys you still can use the https://gitea.example/xoxys/cups-rpm/releases/download/v.1.0.0

IT STILL works - but it there is a problem with name colision/ same names...
"if #9534 got implemented we can switch back to human redable"

so this is the reason why UI using uuid's at the moment

[xoxys]

Ok than I'll still wait

[stale]

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

[xoxys]

Keep until fixed?

[xoxys]

Is there still no fix for it? Even if I can build the readable URLs on my own, it's pretty hard for the "normal" user. I am surprised that I am the only one who is bothered by it 😄

[xuanswe]

I have a related issue with attachment URL. Not sure if I need to create a new ticket or this one will fix it too.

Assuming, I have the gitea configured as http://192.168.1.1:1234.
There's a revert proxy in my local network point to this server: http://gitea.home

If I open a release page http://gitea.home/org/repo/releases, I will have 3 URLs:
Source Code (ZIP) http://gitea.home/org/repo/archive/0.0.1-SNAPSHOT.zip
Source Code (TAR.GZ) http://gitea.home/org/repo/archive/0.0.1-SNAPSHOT.tar.gz
attachment.zip http://192.168.1.1:1234/attachments/a3793480-68ed-48c9-ae70-e57e512383b2

I would expect, the attachment URL use http://gitea.home, same as Source Code URLs.

Note: if I manually enter the URL http://gitea.home/attachments/a3793480-68ed-48c9-ae70-e57e512383b2, it works.

[reivilibre]

I've been finding this inconvenient for tools that wish to be able to download a specific release's binaries for a specific architecture (and it also makes the config files for those much harder to read, since at a glance you can't tell which version is in use).

I had no idea that this was already possible, just 'secret', according to the following scheme (deduced from the messages above):
https://my.gitea/user/project/releases/download/v0.0.1/blahblah-v0.0.1-linux-arm64

[wxiaoguang]

Can we just take the simple fix in #13750 at the moment, and make future PRs for the remaining TODOs? @6543

[drsybren]

I would also welcome more human-readable URLs.

Maybe the URL matching patterns can be altered to accept any name after the UUID? That way a link can be constructed like http://gitea.home/attachments/a3793480-68ed-48c9-ae70-e57e512383b2/original-filename.txt. This ensures that the URL is still unique, but also ensures that doing a wget {url} saves to the correct filename.

Personally this would make my workflow of investigating Blender bug reports a lot easier. What I used to do (before moving to Gitea) was to type wget in a terminal, with the current working directory already set to where I want the file to be, then drag the link from my webbrowser to the terminal (which pastes it after the wget command).