Permanent asset links are erased when updating Releases through the UI
Summary
When updating a release through the Edit Release page, any previously saved permanent asset links are erased.
Steps to reproduce
-
Create a release using the API. Include an asset link with a permanent
filepath
parameter:POST https://gitlab.example.com/api/v4/projects/<project ID>/releases { "tag_name": "v5.11", "ref": "master", "assets": { "links": [ { "url": "https://example.com/link", "name": "An example link", "filepath": "/permanent/link" } ] } }
-
View this newly-created release in the UI by navigating to the Releases page
-
Hover over the asset link. Notice the URL is something like
https://gitlab.example.com/user/project/-/releases/v5.11/downloads/permanent/link
-
Click the pencil icon to edit the release.
-
Without making any changes, save the release.
-
Hover over the asset link again. The URL is now
https://example.com/link
.
What is the current bug behavior?
Updating the release through the UI erases the permanent paths of all its asset links.
What is the expected correct behavior?
Updating the release through the UI should not modify the asset links' permanent paths.
Output of checks
This bug happens on GitLab.com.
Root cause
When a release is saved, each asset link is individually deleted and then recreated. However, the UI doesn't include a field for the permanent URL, so when the link is recreated, it is created without the permanent URL.
The reason links are deleted/created instead of just updated is to avoid edge cases with the link validation (both the URL and name must be unique within the release). This process isn't ideal, and causes other headaches (#220863 (closed)).
Possible fixes
The Edit Release page needs to be made aware of the filepath
parameter. This could mean two things:
- We add a new "Permanent path" input field to the page.
- We make no changes to the UI, and instead just store the permanent path of existing links behind the scenes, and include this information when recreating the links.