### Problem to solve Once https://gitlab.com/gitlab-org/gitlab-ce/issues/56022 is completed, we have a way to generate releases directly in the `.gitlab-ci.yml` and point to a URL as artifact. There's still one big piece missing, however - the ability to create the release binary package itself and put it somewhere that it can be downloaded. This could be a file hosted internally somewhere (GitLabs pages?), a pointer to an artifact link, or a container image reference. ### Target audience TBD ### Further details TBD ### Proposal Allow specifying a local set of files that can be created as a release archive, then make it available at some standard URL within the project. Alternatively, selecting an artifact set and promoting it to be a never-expiring release (something like https://gitlab.com/gitlab-org/gitlab-ce/issues/47878.) Also, pointing to a specific container image. In the existing implementation (https://gitlab.com/gitlab-org/gitlab-ce/issues/56022), building the release package and uploading it somewhere is up to the user (see enumerated steps in `script` section): ```yaml ... runRelease: script: #these are manual tasks implemented by the user, and not automatically handled currently - # do some final release preparation - # manually build release zip - # manually upload release zip to http://my.awesome.download.site/1.0-$CI_COMMIT_SHORT_SHA.zip release: name: My $CI_PROJECT_NAME Release 1.0-$CI_COMMIT_SHORT_SHA tag_name: $CI_COMMIT_TAG ref: $CI_COMMIT_REF_NAME description: | CHANGELOG: - Feature A - Feature B assets: links: [ { name: "Documentation", url: "http://my.awesome.docs.site/1.0-$CI_COMMIT_SHORT_SHA" } { name: "1.0-$CI_COMMIT_SHORT_SHA.zip", url: "http://my.awesome.download.site/1.0-$CI_COMMIT_SHORT_SHA.zip" } ] ... ``` We should refactor this so that something like the following is possible: ```yaml ... runRelease: script: - # do some final release preparation release: name: My $CI_PROJECT_NAME Release 1.0-$CI_COMMIT_SHORT_SHA tag_name: $CI_COMMIT_TAG ref: $CI_COMMIT_REF_NAME description: | CHANGELOG: - Feature A - Feature B assets: links: [ { name: "Documentation", url: "http://my.awesome.docs.site/1.0-$CI_COMMIT_SHORT_SHA" } ] packages: [ { name: "1.0-$CI_COMMIT_SHORT_SHA", format: "zip", path: "output/release" } ] ... ``` In this example, the job would know how to create a zipfile containing everything in the `output/release` folder, and name it with the appropriate filename and extension. We should allow any file format supported for the source code. The file would be automatically uploaded to a repository and a release would be created with a pointer to that URL. The job would then replace the packages section in the yaml with a link and make the appropriate API call to the Release API. ### What does success look like, and how can we measure that? TBD ### Links / references TBD