In GitLab Runner project we've recently started using the [Releases](https://docs.gitlab.com/ee/user/project/releases/) feature (thank you @nolith!). It's something long-awaited by many users and I'm included in this group :wink: At this moment I'm missing only one thing - "direct" links to the Releases and to their assets. For me, the Releases page should be the main source of the release artifacts. For example, for GitLab Runner, when manual installation of the binary is required (MacOS, Windows, FreeBSD - for these OSes we officially support only manual installation of the binary), one needs to know the link to our S3 bucket and needs to know how we're organizing the releases inside of the bucket. What's worse, if we would decide that we like to move out from AWS S3 to GCP GCS (for any reason), all users scripting would be broken after implementing such change. With Releases pages at GitLab, we have a possibility to have such _single source of truth_. Second problem is that currently we can't link to a specific Release. So while it's easy to check information about the most recent ones, accessing the older ones may require a lot of scrolling and clicking the `next` button. ## How it works currently Currently the Releases are just listed at the `https://gitlab.example.com/namespace/project/releases` page. One can't access directly a specified release. Currently, when preparing the Releases entry, one can specify a list of assets. Each asset is described with the name (printed on the Releases page), and the URL (where the asset can be found). On the releases page assets are next linked using the provided URL. This means the to download an asset one still needs to use the direct URL to a target storage. Which may change in the future, thus break installation scripts etc. ## Proposed change 1. ~~Add a `https://gitlab.example.com/namespace/project/releases/:release_id` page. While index page would still print all of them, if I'm interested in checking the details of GitLab Runner v11.0.0 release, I'd like to open a `https://gitlab.com/gitlab-org/gitlab-runner/releases/v11.0.0` page instead of scrolling and changing pages.~~ This has been split out into https://gitlab.com/gitlab-org/gitlab/issues/32827 1. Add a `filename` or rather `filepath` field for an asset description. The filename/filepath would be then used for linking the file. So, again using the GitLab Runner example: - When adding an asset for `v11.9.0-rc2` release, define it as: ```json { "name": "linux amd64", "filepath": "binaries/gitlab-runner-linux-amd64", "url": "https://gitlab-runner-downloads.s3.amazonaws.com/v11.9.0-rc2/binaries/gitlab-runner-linux-amd64" } ``` - On the release/releases page, instead of linking the `linux amd64` file of `v11.9.0-rc2` release as `https://gitlab-runner-downloads.s3.amazonaws.com/v11.9.0-rc2/binaries/gitlab-runner-linux-amd64` (the target URL where the file is stored) it should be linked as `https://gitlab.com/gitlab-org/gitlab-runner/releases/v11.9.0-rc2/binaries/gitlab-runner-linux-amd64`. Notice that the `filepath` is added to the release direct page. - To not force GitLab to proxy the download, it should just respond with HTTP 302 code pointing to `https://gitlab-runner-downloads.s3.amazonaws.com/v11.9.0-rc2/binaries/gitlab-runner-linux-amd64` (the value of `url`). Every downloading tool that properly supports HTTP should handle this without problems. Thanks to this, the Release is no longer coupled with the storage of it assets. One can start moving files from S3 to GCS, own servers or anything else, but as long as the URL on Releases page is pointing to it, the file will be still accessible from the very same URL: `https://gitlab.com/namespace/project/releases/:release_id/:filepath`. GitLab may be a main source of the source code repository, issues, community interactions via MRs. Let's make the Releases feature the main source of project releases, removing the tight bonding with used storage :wink: ## UX Proposal [SEE DESIGNS OF RELEASE PAGE ENTRY](https://gitlab.com/gitlab-org/gitlab/issues/32827/designs/12.7-release_page-entry.png) ## MR breakdown - add filepath column to release_links - validations for filepath column - routing and controller changes for redirect - documentation <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->