Release Workflows

Here is an example shell script for a release workflow using Nexigon:

#!/usr/bin/env bash

set -euo pipefail

REPOSITORY="example-repo"
PACKAGE="example-repo/example-pkg"

# Version to release, e.g., obtained with `git describe`.
version=$(git describe --always)

# Create a new version with an appropriate, locked tag. Note that we do not
# assign the `latest` tag here. There are no assets yet and we would not like
# clients to pick up this new version without assets.
version_id=$( \
    nexigon-cli repositories versions create $PACKAGE --tag $version,locked \
    | jq -r '.versionId' \
)

# Now, upload and assign the assets.
asset_path="assets/example-asset"
asset_id=$( \
    nexigon-cli repositories assets upload $REPOSITORY $asset_path \
    | jq -r '.assetId' \
)
nexigon-cli repositories versions assets add $version_id $asset_id $(basename $asset_path)

# After uploading and assigning all the assets. We tag the version with the
# `latest` tag. Note that this will atomically reassign the `latest` tag thereby
# making the new version the latest version.
nexigon-cli repositories versions tag $version_id --tag latest,reassign

Note that this script assumes that a version with the respective locked tag does not already exist. If you want to upload assets to an already existing version, you can use versions resolve to check whether the version already exists.

One way to implement a multi-stage release process is to tag the new version with testing or staging first. You can then deploy the version, e.g., to canary devices or within a staging environment, and run additional tests. Only after validating the quality of the version, you then promote the version to latest or stable, making it available to production devices.

We are using a similar script to upload and release Nexigon CLI and Nexigon Agent.