Gitlab Releases: create versions and serve files
Introduction
Define releases is very important to control your code versions. Without this resource is very difficult to upgrade or to make a regression (rollback), if necessary. Create it with Gitlab is simple and very useful, not only for definitions but also to serve specific files for some application. In this post I will approach the release concept, how to create releases at Gitlab and also how to use them to serve codes.
Release: what is it?
Releases are code versions that are send to production and are available to the users. They mark the point that the code is stable after some feature or bug fix implementation. As a developer we create a lot of commits, so mark those stable points are essential to guarantee a secure deploy (secure about the consistency).
Gitlab releases
You can manage your releases by your own making some notes about it in some place or in your commit, but to centrelize all this information in the same repo in a space created for that could be very useful (including to the next topic that will be approached).
1. Create and push tags
Gitlab releases are based on tags, so the first thing is to mark your code with tags that point the releases:
git tag <tag-name> // to create your tag (at the current commit)
git push origin <tag-name> // to push it to gitlab repo at origin repo
After create and push them, you will see your tags at gitlab marked in the respective commits, like 2.2.3, 2.2.1 and 2.1.0 in the image below:
2. Create the releases based on the tags
In your main page look for releases in the right side:
Select the option New release to create a new one. After that select the tag that will mark the release, add a title and also a description. It's very important that you describe the changes that will be applied in this release, like new features or bug fixes. Here is a release note example:
Now your release is created and with it will be available your source code, release json (with all information) and description.
Gitlab API for releases
Just to create releases at Gitlab is great and organize your repo and versions. However, the Gitlab also offers an API to serve all your available releases, and this resource enables a lot of fantastic implementations.
To access your releases information is very simple, you just need of your repo ID, that can be found at repo main page, and an access token, for private repositories:
curl --header "PRIVATE-TOKEN: <your_token>" "https://gitlab.com/api/v4/projects/:id/releases"
// Public repo
curl https://gitlab.com/api/v4/projects/:id/releases
Before to list possible uses, a important note to do is that it is easier to work with a public repo (if you have a lot of clients and want to guarantee no problem with tokens expiration or removal, for example), but note that the source code is always available in releases, something that is being discussed for a while in community issue#232074, so keep this in mind if you decide to make this move.
1. List all releases
The response for this request is a list containing all releases with a lot of information like release name, tag, author, repo, etc. With this you can load for the user, for example, all past and current releases and also the descriptions for each one. See here a response example.
2. Serve files
Links can be added to your release, with this you can add for example a link to your .bin file and register on your board to always look for updates from the latest release. If the file is in your repository you can just add the download link, it is not necessary to host somewhere else.
Conclusion
This is only one of Gitlab API uses, the great news is that this API support variables resources, not only releases. The options are many, you could use this instead create your own API if you want to serve simple and public information, for example.
See Gitlab API documentation for more.
Comments
Post a Comment