How to store releases/binaries in GitLab?
I am building a workflow with Gitlab, Jenkins and - probably - Nexus (I need an artifact storage). I would like to have GitLab to store releases/binaries - is it possible in a convenient way?
I would not like to have another service from which a release (and documentation) could be downloaded but to have it somehow integrated with repository manager, just like releases are handled in e.g. GitHub. Any clues?
Answer
Update Oct. 2020:
GitLab 13.5 now offers:
Attach binary assets to Releases
If you aren’t currently using GitLab for your releases because you can’t attach binaries to releases, your workflow just got a lot simpler.
You now have the ability to attach binaries to a release tag from the
gitlab.ci-yml. This extends support of Release Assets to include binaries, rather than just asset links or source code. This makes it even easier for your development teams to adopt GitLab and use it to automate your release process.
See Documentation and Issue.
Update Nov. 2015: GitLab 8.2 now supports releases.
With its API, you now can create and update a relase associated to a tag.
For now, it is only the ability to add release notes (markdown text and attachments) to git tags (aka Releases).
- first upload the release binary
- create a new release and place a link to the uploaded binary in the description
Update May 2019: GitLab 1.11 introduces an interesting "Guest access to Releases":
It is now possible for guest users of your projects to view releases that you have published on the Releases page.
They will be able to download your published artifacts, but are not allowed to download the source code nor see repository information such as tags and commits.
Original answer March 2015
This is in progress, and suggested in suggestions 4156755:
We’re accepting merge requests for the minimal proposal by Ciro:
- For each repository tag under https://github.com/cirosantilli/test/releases/tag/3.0, allow to upload and download a list of files. 2. The upload and download can be done directly from the tag list view. 3. If a tag gets removed, the uploads are destroyed. (we’re not accepting the tag message edit mentioned in recent comments)
The comments to that suggestion include:
What makes it more interesting is the next step.
I would really like a way to let public download artifacts from "releases" without being able to access source code (i.e. make sources private for project team only except anything else like wiki, "releases", issue tracker).
However, such additional feature looks more generic and I submitted a separate feature request for that.
Nevertheless, I repeat my point here:
While the simplistic version of "releases" is still nice to have, many people can easily set up external file server and point URLs in release/tag description to this server outside GitLab.
In other words, "releases" may not look attractive now without some future picture of integration.