Add more Release artifact types
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):
...
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:
...
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