Tag
In order to identify specific state of your work, you may want to tag any given commit. Once created, you will find your tag in the tags list on the Releases & Tags page, which will allow you to download, revert your working state to that specific tagged state, etc.
From the Branch Management page:
- Click on the Tag button next to the commit that you want to tag.
- Fill in the pop-up window with a tag name and a description.
The On Commit field is in read-only and automatically filled, it will display the name of the tag where the release is done.
- Click on Ok. Your project is tagged.
Once you have created a new tag, it will be available from the tags tab on the Releases & Tags page, where you will be available to manage your tags.
Release
A release is considered as a tested and validated version of your project. Once created, you will be able to use this stable version in production.
From the Studio Modeler
Go to Source Control > Branch Management:
- Click on the Release button next to the commit that you want to release.
- Fill in the pop-up window:
All the fields will be pre-filled but you can modify the released version and prepare your next version by checking the Next version box. You will be able to choose the type of your release or to create a custom one with a qualifier.
Once your release is created, you can now install it like you would install any other Nuxeo package.
With the REST API
To create a release you need:
- Your project identifier
- Credentials with write access to the project
- The revision on which the release will be created. This can be master or a feature branch, but not a user workspace branch
- Either the name of the release that will be created, or the type of release you want to create (see below).
Versions in Studio must have the following format: M.m.p[-q] where:
- M is the major number. It should be incremented when new features are added and APIs were broken
- m is the minor number. It should be incremented when new features are added and no API was broken
- p is the patch number. It should be incremented when the release contains only bug fixes
- q is the qualifier string. It qualifies the release, eg: beta, rc1. Must contain only letters, numbers, '_', '-' or '.'
For automation purposes it might be preferable to ask Studio to choose the next version type: MAJOR, MINOR or PATCH instead of specifying a version name. Studio will look for the latest release created in the history of the revision commit and try to release the next version as asked.
If the version name specified (or computed by Studio) already exists, then the release will not be allowed and will fail.
Request:
POST https://connect.nuxeo.com/nuxeo/site/studio/v2/project/{project_id}/releases
Authorization: Basic base64({username}:{token})
Accept: application/json
Content-Type: application/json
{
"revision": "{branch_name}",
"versionName": "(M.m.p-q|MAJOR|MINOR|PATCH)"
}
Response:
Content-Type: application/json
{
"version": "M.m.p-q",
"bundleSymbolicName": "studio.extensions.{project_id}",
"mavenCoordinates": "{project_group_id}:{project_id}:M.m.p-q"
}
Example creating a minor release on master as John Doe on my-project with curl:
curl -X POST \
-H 'Content-Type: application/json' \
-d '{ "revision": "master", "versionName": "MINOR" }' \
-u 'jdoe:token' \
'https://connect.nuxeo.com/nuxeo/site/studio/v2/project/my-project/releases'