To release emerald you should use the maven-release-plugin. Our process differs from the default process in some areas so please follow these instructions closely.
Start by raising an issue to tag the release (we can't push directly to master so you have to do a release from a feature branch).
Create a feature branch off master for the given issue number:
git checkout master
git checkout -b feature/#
Run the maven release prepare command:
You will be prompted for 3 values; The release version - this should follow Semantic Versioning 2.0, the release tag - this should match the release version with a v before it (i.e. release version 1.0.0, tag = v1.0.0) and finally the next development version - this should be the next proposed development version with -SNAPSHOT on the end e.g. 1.1.0-SNAPSHOT
The build will proceed to check for no local modifications, it will then tag the codebase in source control and run a full clean / install / integration-test cycle to ensure the tag is valid
Assuming the build succeeds you should run the release cleanup job:
Finally merge your feature branch back to master in the gitlab web ui and remove the branch
Should the build fail then you can revert the changes in your working copy by doing the following:
Note that this doesn't delete the tag from source control - you will either need to manually remove the tag and re-run the release process (having fixed the build problems) or alternatively move to another tag. To avoid the need to delete and re-create tags I suggest you create release candidate tags and ensure they are fully building before committing to a final version tag. e.g. v1.0.0-rc1, v1.0.0-rc2 ... until you are entirely comfortable, then v1.0.0.
You might ask why you don't need to run a release:perform step in maven - this is because we are not using maven's deployment process and therefore a release:prepare is enough to create a test a tag version in source control.