Add the release tagging script (#347)

* Add the release tagging script

* Update RELEASING.md

Co-authored-by: Anna U <[email protected]>

Author: Mateusz Rzeszutek

RELEASING.md

@@ -2,28 +2,30 @@
 
 ## Releasing a new version
 
-Releasing of splunk-otel-android is done via a private Splunk gitlab installation.
+splunk-otel-android is released via a private Splunk gitlab installation.
 
 This is the process to use to do a release:
 
-1) Use the _Github_ UI to create a tag for the version (by creating a pre-release, for example),
-pointing at the commit SHA on the main branch that you want to release.
-The format of the tag should be "vx.y.z" or it won't be picked
-up by gitlab as a release tag. You can also create a tag via the command line and push it to github
-if you are more comfortable with that process.
+1) Make sure that all the required changes are merged. This includes updating the upstream OTel
+   libraries' versions, and making sure that the project version in the `gradle.properties` file is
+   correctly set to the next planned release version.
 
-2) Wait for gitlab to run the release job.
+2) Run the `scripts/tag-release.sh` script to create and push a signed release tag. Note that it
+   assumes that the remote is named `origin`, if you named yours differently you might have to push
+   the tag manually.
 
-3) Log in to oss.sonatype.org with a login that has permissions to see and release the `com.splunk`
-staging repository.
+3) Wait for gitlab to run the release job.
 
-4) Close the staging repository, and then release it via the oss.sonatype.org UI.
-Ideally, verify that the publishing worked by pulling down the dependency in some sample project and
-build an application against it, as a double-check that it is a working release.
+4) Log in to `oss.sonatype.org` with a profile that has permissions to see and release the `com.splunk`
+   staging repository.
 
-5) Create a PR that will update the version in the `gradle.properties` to the next one that will be being worked on.
-This PR can and probably should also include updating any documentation (CHANGELOG.md, README.md, etc)
-that mentions the previous version.
+5) Close the staging repository, and then release it via the oss.sonatype.org UI.
+   Ideally, verify that publishing worked by pulling down the dependency in some sample project
+   and build an application against it. This will double-check that it's a working release.
 
-6) Once this PR is merged, create a release in Github that points at the newly created version, make sure
-to provide release notes that at least mirror the contents of the CHANGELOG.md
+6) Create a PR to update the version in the `gradle.properties` to the next development
+   version. This PR can and probably should also include updating any documentation (CHANGELOG.md,
+   README.md, etc) that mentions the previous version.
+
+7) Once this PR is merged, create a release in Github that points at the newly created version,
+   and make sure to provide release notes that at least mirror the contents of the CHANGELOG.md

scripts/tag-release.sh

@@ -0,0 +1,34 @@
+#!/usr/bin/env bash
+
+set -e
+
+SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
+ROOT_DIR="${SCRIPT_DIR}/../"
+cd ${ROOT_DIR}
+
+print_usage() {
+  cat <<EOF
+Usage: $(basename $0) release_version
+
+All versions MUST NOT begin with 'v'. Example: 1.2.3.
+EOF
+}
+
+if [[ $# < 1 ]]
+then
+  print_usage
+  exit 1
+fi
+
+release_version=$1
+release_tag="v$1"
+
+if [[ ! $release_version =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]
+then
+  echo "Invalid release version: $release_version"
+  echo "Release version must follow the pattern major.minor.patch, e.g. 1.2.3"
+  exit 1
+fi
+
+git tag -m "Release $release_version" -s "$release_tag"
+git push origin "$release_tag"