Release Config

Release configuration is a fundamental setup that outlines the organisation of packages within a project, streamlining across different lifecycle of your project, such as validating, building, deploying/release of artifacts. In flxbl projects, a release config is used to define the concept of a domain/subdomains.

This configuration is instrumental when using sfp commands, as it allows for selective operations on specified packages defined by a configuration. By employing a release configuration, teams can efficiently manage a mono repository of packages across various teams.

---
releaseName: core
pool: core_pool
includeOnlyArtifacts:
  - src-env-specific-pre
  - src-env-specific-alias-pre
  - core-crm
  - telephony-service
excludePackageDependencies:
  - Genesys Cloud for Salesforce
  - Marketing Cloud
releasedefinitionProperties:
  changelog:
    workItemFilters:
      -  BRO-[0-9]{3,4}
    workItemUrl: https://bro.atlassian.net/browse
    limit: 30

A release config is validated against its schema when loaded. A config that fails validation aborts the command with the list of validation errors.

The table below lists the options that are currently available for release configuration

ParameterRequiredTypeDescription
releaseNameYesStringName of the release config, in flxbl project, this name is used as the name of the domain
poolNoStringName of the scratch org or sandbox pool associated with this release config during validation
excludeArtifactsNoArrayAn array of artifacts that need to be excluded while creating the release definition. Cannot be combined with includeOnlyArtifacts
includeOnlyArtifactsNoArrayAn array of artifacts that should only be included while creating the release definition. Cannot be combined with excludeArtifacts
dependencyOnNoArrayAn array of packages that denotes the dependency this configuration has. The dependencies mentioned will be used for synchronization in review sandboxes. Ignored when dependencyOnDomains is set
dependencyOnDomainsNoArrayNames of other release configs (domains) this domain depends on. Every package of the listed domains — and of the domains they depend on, resolved recursively — is treated as a dependency of this domain. Takes precedence over dependencyOn. See Cross-domain dependencies
excludeAllPackageDependenciesNoBooleanWhen true, no package dependencies are carried into the generated release definition
excludePackageDependenciesNoArrayExclude the mentioned package dependencies from the release definition. Cannot be combined with includeOnlyPackageDependencies
includeOnlyPackageDependenciesNoArrayInclude only the mentioned package dependencies from the release definition. Cannot be combined with excludePackageDependencies
packageDependenciesNoObjectExplicit external package dependencies (package name → a 04t subscriber package version id or a four-part version number such as 1.4.4.LATEST) copied into the generated release definition. Kept in declaration order — release installs them sequentially, so list prerequisites first. An entry overrides a discovered dependency of the same name.
releasedefinitionPropertiesNoObjectProperties of release definition that should be added to the generated release definition. See below

Cross-domain dependencies (dependencyOnDomains)

dependencyOnDomains declares a domain's dependencies as other release configs, referenced by their releaseName, instead of listing individual packages with dependencyOn.

releaseName: sales
includeOnlyArtifacts:
  - sales-crm
  - sales-ui
dependencyOnDomains:
  - core

Resolution is recursive: a listed domain's own dependencyOnDomains are followed, and every package of every reachable domain becomes a dependency of this one. Packages are ordered deepest dependency first and de-duplicated. The resolved packages are used wherever domain dependencies apply — validation, review sandbox synchronization, and pool preparation, where the pooled orgs also install the dependency domains' packages.

When dependencyOnDomains is set, dependencyOn is ignored. Resolution fails when a listed domain does not exist or when the domain graph contains a cycle.

Release definition properties

A release configuration also can contain additional options that can be used by certain sfp commands to generate release definitions. These properties in a release definiton alters the behaviour of deployment of artifacts during a release

ParameterRequiredTypeDescription
releasedefinitionProperties.skipIfAlreadyInstalledNobooleanSkip installation of artifact if it's already installed in target org
releasedefinitionProperties.skipArtifactUpdateNobooleanWhen true, a release does not update the installed-artifact records in the target org after deployment; the org's record of installed versions is left unchanged
releasedefinitionProperties.baselineOrgNostringThe org used to decide whether to skip installation of an artifact. Requires skipIfAlreadyInstalled to be true. Defaults to the target org when not provided
releasedefinitionProperties.promotePackagesBeforeDeploymentToOrgNostringPromote packages before they are installed into an org that matches alias of the org
releasedefinitionProperties.changelog.workItemFiltersYes, when changelog is setarrayAn array of regular expression used to identify work items in your commit messages
releasedefinitionProperties.changelog.workItemUrlNostringThe 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.
releasedefinitionProperties.changelog.limitNointegerLimit the number of releases to display in the changelog markdown
releasedefinitionProperties.changelog.showAllArtifactsNobooleanWhether to show artifacts that haven't changed between releases

On this page