Release
The orchestrator:release command brings uniformity to the CI/CD landscape, allowing you to define 'releases' no matter which platform you are on. A release is defined by a YAML file, where you can specify the artifacts to be installed in the org, in addition to other parameters. The release will then be orchestrated based on the configuration of the YAML definition file.

Release definition

1
# release-definition.yaml
2
3
release: "release-1.0"
4
skipIfAlreadyInstalled: true
5
baselineOrg: "myorg"
6
promotePackagesBeforeDeploymentToOrg:"SIT"
7
artifacts:
8
mypackageA: LATEST_GIT_TAG or LATEST_TAG
9
mypackageB: LATEST_TAG # Substituted with version from latest git tag at runtime
10
mypackageC: 1.2.3-5 # Provide the exact version to download
11
packageDependencies:
12
Marketing Cloud: 04t0H000000xVrw
13
changelog:
14
repoUrl: "https://github.com/myorg/myrepo.git"
15
workItemFilter: "BRO-[0-9]{3,4}"
16
workItemUrl: "https://www.atlassian.com/software/jira"
17
limit: 30
18
showAllArtifacts: false
Copied!
Parameter
Required
Type
Description
release
Yes
string
Name of the release
skipIfAlreadyInstalled
No
boolean
Skip installation of artifact if it's already installed in target org
baselineOrg
No
string
The org used to decide whether or not to skip installation of an artifact. Defaults to the target org when not provided.
artifacts
Yes
Object
Map of artifacts to deploy and their corresponding version
promotePackagesBeforeDeploymentToOrg
No
string
Promote packages before they are installed into an org that matches alias of the org
packageDependencies
No
Object
Packages dependencies (e.g. managed packages) to install as part of the release. Provide the 04t subscriber package version Id.
changelog.repoUrl
No
Prop
The URL of the version control system to push changelog files
changelog.workItemFilter
No
Prop
A regular expression used to identify work items in your commit messages
changelog.workitemUrl
No
Prop
The generic URL of work items, to which to append work item codes. Allows easy redirection to user stories by clicking on the work-item link in the changelog.
changelog.limit
No
Prop
Limit the number of releases to display in the changelog markdown
changelog.showAllArtifacts
No
Prop
Whether to show artifacts that haven't changed between releases

Fetching Artifacts for Release

The orchestrator:release command provides a simplified method of fetching artifacts from an artifact repository using the release definition file which contains the name of the artifacts that you want to download, and a mapping to the version to download. If fetching from a NPM registry, the command will handle everything else for you. However, for universal artifacts there is no uniform method for downloading artifacts from a repository, so you will need to provide a shell script that calls the relevant API.
TheLATEST_TAG keyword is only supported if the current working directory is pointing to the project directory, and if at least one git tag exists for the package.

Fetching universal artifacts

For universal artifacts, there is no uniform method for downloading artifacts from a registry, so you will need to provide a shell script that calls the relevant API. You need to pass the path to script file using the flag --scriptpath
There are multiple parameters available in the shell script. Pass these parameters to the API call, and at runtime they will be substituted with the corresponding values:
  1. 1.
    Artifact name
  2. 2.
    Artifact version
  3. 3.
    Directory to download artifacts
Eg. Fetching from Azure Artifacts using the Az CLI on Linux
1
#!/bin/bash
2
3
# $1 - artifact name
4
# $2 - artifact version
5
# $3 - artifact directory
6
7
echo "Downloading Artifact $1 Version $2"
8
9
az artifacts universal download --feed myfeed --name $1 --version $2 --path $3 \
10
--organization "https://dev.azure.com/myorg/" --project myproject --scope project
Copied!

Changelog

When the --generatechangelog flag is passed to the command, a changelog will automatically be generated if the release is successful. The changelog provides traceability for the artifacts, work items and commits that were introduced by each release, as well as an at-a-glance view of all your orgs and which release they are currently on.
To generate a changelog, thechangelog.repoUrlandchangelog.workItemFilter parameters must be configured in the release definition file.
A changelog is generated in markdown format and pushed to the repo, utilizing thebranchname flag provided to the release command. If the command finds a previous changelog files, it will utilize to generate an incremental changelog
Release changelog
Last modified 1mo ago