Create a package version in the Dev Hub org.
The package version is based on the package contents in the specified directory.
To retrieve details about a package version create request, including status and package version ID (04t), run "<%= config.bin %> package version create report -i 08c...".
We recommend that you specify the --installation-key parameter to protect the contents of your package and to prevent unauthorized installation of your package.
To list package version creation requests in the org, run "<%= config.bin %> package version create list". To promote a package version to released, you must use the --code-coverage parameter. The package must also meet the code coverage requirements. This requirement applies to both managed and unlocked packages.
We don’t calculate code coverage for org-dependent unlocked packages, or for package versions that specify --skip-validation.
-
Create a package version from the contents of the "common" directory and give it an installation key of "password123"; uses your default Dev Hub org:
<%= config.bin %> <%= command.id %> --path common --installation-key password123
-
Create a package version from a package with the specified alias; uses the Dev Hub org with username devhub@example.com:
<%= config.bin %> <%= command.id %> --package "Your Package Alias" --installation-key password123 --target-dev-hub devhub@example.com
-
Create a package version from a package with the specified ID:
<%= config.bin %> <%= command.id %> --package 0Ho... --installation-key password123
-
Create a package version and skip the validation step:
<%= config.bin %> <%= command.id %> --path common --installation-key password123 --skip-validation
-
Create a package version and perform package validations asynchronously:
<%= config.bin %> <%= command.id %> --path common --installation-key password123 --async-validation
ID (starts with 0Ho) or alias of the package to create a version of.
Path to the directory that contains the contents of the package.
Path to a definition file similar to scratch org definition file that contains the list of features and org preferences that the metadata of the package version depends on.
For a patch version, the features specified in this file are ignored, and instead the features specified for the ancestor version are used.
Name of the branch in your source control system that the package version is based on.
Package version’s tag.
Installation key for key-protected package. (either --installation-key or --installation-key-bypass is required)
Bypass the installation key requirement. (either --installation-key or --installation-key-bypass is required)
If you bypass this requirement, anyone can install your package.
Preserve temp files that would otherwise be deleted.
Validate the sfdx-project.json file against the JSON schema.
The temp files are located at: %s.
Number of minutes to wait for the package version to be created.
Instance where the package version will be created, such as NA50.
Name of the package version to be created; overrides the sfdx-project.json value.
Version number of the package version to be created; overrides the sfdx-project.json value.
For information about the format of the version number, see https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/sfdx_dev2gp_config_file.htm.
Description of the package version to be created; overrides the sfdx-project.json value.
Calculate and store the code coverage percentage by running the packaged Apex tests included in this package version.
Before you can promote and release a managed or unlocked package version, the Apex code must meet a minimum 75% code coverage requirement. We don’t calculate code coverage for org-dependent unlocked packages or for package versions that specify --skip-validation.
Release notes URL.
This link is displayed in the package installation UI to provide release notes for this package version to subscribers.
Skip validation during package version creation; you can’t promote unvalidated package versions.
Skips validation of dependencies, package ancestors, and metadata during package version creation. Skipping validation reduces the time it takes to create a new package version, but you can promote only validated package versions. Skipping validation can suppress important errors that can surface at a later stage. You can specify skip validation or code coverage, but not both. Code coverage is calculated during validation.
Skipping validation suppresses errors that usually surface during package version creation. Instead, these errors surface at a later stage, such as installation or post-installation. If you encounter errors that are difficult to debug, retry package version creation without the --skip-validation parameter.
Return a new package version before completing package validations.
Specifying async validation returns the package version earlier in the process, allowing you to install and test the new version right away. If your development team is using continuous integration (CI) scripts, async validation can reduce your overall CI run time.
Generate a package ZIP file that you can use for debugging or to examine the package contents.
Override ancestry requirements, which allows you to specify a package ancestor that isn’t the highest released package version.
Post-install instructions URL.
The contents of the post-installation instructions URL are displayed in the UI after installation of the package version.
Name of the post-install script; applies to managed packages only.
The post-install script is an Apex class within this package that is run in the installing org after installations or upgrades of this package version.
Uninstall script name; applies to managed packages only.
The uninstall script is an Apex class within this package that is run in the installing org after uninstallations of this package.
Language for the package.
Specify the language using a language code listed under "Supported Languages" in Salesforce Help. If no language is specified, the language defaults to the language of the Dev Hub user who created the package.
Display verbose command output.
Display verbose command output. When polling for the status of the creation, this will output status and timeout data on a separate line for each poll request, which is useful in CI systems where timeouts can occur with long periods of no output from commands.
Package version creation request status is '%s'. Run "%s package version create report -i %s" to query for status.
Successfully created the package version [%s]. Subscriber Package Version Id: %s Package Installation URL: %s%s As an alternative, you can use the "%s package install" command.
The directory [%s] doesn’t exist in the current directory.
Multiple errors occurred: %s
Version create.
%d minutes remaining until timeout. Create version status: %s
The validations for this package version are in progress, but you can now begin testing this package version. To determine whether all package validations complete successfully, run "sf package version create report --package-create-request-id 08cxx" and review the Status. Async validated package versions can be promoted only if all validations complete successfully.
Create version status: %s
An unknown error occurred.
This package contains more than %s metadata files. The maximum number of metadata files in a package is %s. If you reach the file limit, you won’t be able to create new package versions. To confirm the exact file count for this package, run sf package version report and review the “# Metadata Files” column.
The maximum size of all the metadata files size in a single package is %s MB. The package version you’re creating exceeds 70% of the metadata file size limit. If you reach the file size limit, you won’t be able to create new package versions. To confirm the exact file size for this package, run "sf package version report" and review the “Metadata File Size” column.