codePush release-react命令参数解释

Releasing Updates (React Native)

code-push release-react

[--bundleName ]

[--deploymentName ]

[--description ]

[--development ]

[--disabled ]

[--entryFile ]

[--gradleFile ]

[--mandatory]

[--noDuplicateReleaseError]

[--outputDir ]

[--plistFile ]

[--plistFilePrefix ]

[--sourcemapOutput ]

[--targetBinaryVersion ]

[--rollout ]

[--privateKeyPath ]

The release-react command is a React Native-specific version of the "vanilla" release command, which supports all of the same parameters (e.g. --mandatory, --description), yet simplifies the process of releasing updates by performing the following additional behavior:

1. Running the react-native bundle command in order to generate the update contents (JS bundle and assets) that will be released to the CodePush server. It uses sensible defaults as much as possible (e.g. creating a non-dev build, assuming an iOS entry file is named index.ios.js), but also exposes the relevant react-native bundleparameters to enable flexibility (e.g. --sourcemapOutput).
   
2. Inferring the targetBinaryVersion of this release by using the version name that is specified in your project's Info.plist (for iOS) and build.gradle (for Android) files.
   

To illustrate the difference that the release-react command can make, the following is an example of how you might generate and release an update for a React Native app using the "vanilla" release command:

mkdir ./CodePush

react-native bundle --platform ios \

--entry-file index.ios.js \

--bundle-output ./CodePush/main.jsbundle \

--assets-dest ./CodePush \

--dev false

code-push release MyApp-iOS ./CodePush 1.0.0

Achieving the equivalent behavior with the release-react command would simply require the following command, which is generally less error-prone:

code-push release-react MyApp-iOS ios

NOTE: We believe that the release-react command should be valuable for most React Native developers, so if you're finding that it isn't flexible enough or missing a key feature, please don't hesistate to let us know, so that we can improve it!

App name parameter

This specifies the name of the CodePush app that this update is being released for. This value corresponds to the friendly name that you specified when originally calling code-push app add (e.g. "MyApp-Android"). If you need to look it up, you can run the code-push app ls command to see your list of apps.

Platform parameter

This specifies which platform the current update is targeting, and can be either android, ios or windows (case-insensitive). This value is only used to determine how to properly bundle your update contents and isn't actually sent to the server.

Deployment name parameter

This specifies which deployment you want to release the update to. This defaults to Staging, but when you're ready to deploy to Production, or one of your own custom deployments, just explicitly set this argument.

NOTE: The parameter can be set using either "--deploymentName" or "-d".

Description parameter

This provides an optional "change log" for the deployment. The value is simply round tripped to the client so that when the update is detected, your app can choose to display it to the end-user (e.g. via a "What's new?" dialog). This string accepts control characters such as \n and \t so that you can include whitespace formatting within your descriptions for improved readability.

NOTE: This parameter can be set using either "--description" or "-des"

Mandatory parameter

This specifies whether the update should be considered mandatory or not (e.g. it includes a critical security fix). This attribute is simply round tripped to the client, who can then decide if and how they would like to enforce it.

NOTE: This parameter is simply a "flag", and therefore, its absence indicates that the release is optional, and its presence indicates that it's mandatory. You can provide a value to it (e.g. --mandatory true), however, simply specifying --mandatory is sufficient for marking a release as mandatory.

No duplicate release error parameter

This specifies that if the update is identical to the latest release on the deployment, the CLI should generate a warning instead of an error. This is useful for continuous integration scenarios where it is expected that small modifications may trigger releases where no production code has changed.

Rollout parameter

IMPORTANT: In order for this parameter to actually take affect, your end users need to be running version 1.6.0-beta+ (for Cordova) or 1.9.0-beta+ (for React Native) of the CodePush plugin. If you release an update that specifies a rollout property, no end user running an older version of the Cordova or React Native plugins will be eligible for the update. Therefore, until you have adopted the neccessary version of the platform-specific CodePush plugin (as previously mentioned), we would advise not setting a rollout value on your releases, since no one would end up receiving it.

This specifies the percentage of users (as an integer between 1 and 100) that should be eligible to receive this update. It can be helpful if you want to "flight" new releases with a portion of your audience (e.g. 25%), and get feedback and/or watch for exceptions/crashes, before making it broadly available for everyone. If this parameter isn't set, it is set to 100%, and therefore, you only need to set it if you want to actually limit how many users will receive it.

When leveraging the rollout capability, there are a few additional considerations to keep in mind:

1. You cannot release a new update to a deployment whose latest release is an "active" rollout (i.e. its rollout property is non-null). The rollout needs to be "completed" (i.e. setting the rollout property to 100) before you can release further updates to the deployment.
   
2. If you rollback a deployment whose latest release is an "active" rollout, the rollout value will be cleared, effectively "deactivating" the rollout behavior
   
3. Unlike the mandatory and description fields, when you promote a release from one deployment to another, it will not propagate the rollout property, and therefore, if you want the new release (in the target deployment) to have a rollout value, you need to explicitly set it when you call the promote command.
   

NOTE: This parameter can be set using either --rollout or -r

If left unspecified, the release will be made available to all users.

Target binary version parameter

This specifies the store/binary version of the application you are releasing the update for, so that only users running that version will receive the update, while users running an older and/or newer version of the app binary will not. This is useful for the following reasons:

1. If a user is running an older binary version, it's possible that there are breaking changes in the CodePush update that wouldn't be compatible with what they're running.
   
2. If a user is running a newer binary version, then it's presumed that what they are running is newer (and potentially incompatible) with the CodePush update.
   

If you ever want an update to target multiple versions of the app store binary, we also allow you to specify the parameter as a semver range expression. That way, any client device running a version of the binary that satisfies the range expression (i.e. semver.satisfies(version, range) returns true) will get the update. Examples of valid semver range expressions are as follows:

Range Expression Who gets the update

1.2.3 Only devices running the specific binary app store version 1.2.3 of your app

* Any device configured to consume updates from your CodePush app

1.2.x Devices running major version 1, minor version 2 and any patch version of your app

1.2.3 - 1.2.7 Devices running any binary version between 1.2.3 (inclusive) and 1.2.7 (inclusive)

>=1.2.3 <1.2.7 Devices running any binary version between 1.2.3 (inclusive) and 1.2.7 (exclusive)

1.2 Equivalent to >=1.2.0 <1.3.0

~1.2.3 Equivalent to >=1.2.3 <1.3.0

^1.2.3 Equivalent to >=1.2.3 <2.0.0

*NOTE: If your semver expression starts with a special shell character or operator such as >, ^, or ** , the command may not execute correctly if you do not wrap the value in quotes as the shell will not supply the right values to our CLI process. Therefore, it is best to wrap your targetBinaryVersion parameter in double quotes when calling the release command, e.g. code-push release MyApp-iOS updateContents ">1.2.3".

If left unspecified, this defaults to targeting the exact version specified in the app's Info.plist (for iOS) and build.gradle (for Android) files.

Bundle name parameter

This specifies the file name that should be used for the generated JS bundle. If left unspecified, the standard bundle name will be used for the specified platform: main.jsbundle (iOS), index.android.bundle (Android) and index.windows.bundle (Windows).

NOTE: This parameter can be set using either --bundleName or -b

Development parameter

This specifies whether to generate a unminified, development JS bundle. If left unspecified, this defaults to falsewhere warnings are disabled and the bundle is minified.

NOTE: This parameter can be set using either --development or --dev

Disabled parameter

This specifies whether an update should be downloadable by end users or not. If left unspecified, the update will not be disabled (i.e. users will download it the moment your app calls sync). This parameter can be valuable if you want to release an update that isn't immediately available, until you expicitly patch it when you want end users to be able to download it (e.g. an announcement blog post went live).

NOTE: This parameter can be set using either "--disabled" or "-x"

Entry file parameter

This specifies the relative path to the app's root/entry JavaScript file. If left unspecified, this defaults to index.ios.js(for iOS), index.android.js (for Android) or index.windows.bundle (for Windows) if that file exists, or index.jsotherwise.

NOTE: This parameter can be set using either --entryFile or -e

Gradle file parameter (Android only)

This specifies the relative path to the build.gradle file that the CLI should use when attempting to auto-detect the target binary version for the release. This parameter is only meant for advanced scenarios, since the CLI will automatically be able to find your build.grade file in "standard" React Native projects. However, if your gradle file is located in an arbitrary location, that the CLI can't discover, then using this parameter allows you to continue releasing CodePush updates, without needing to explicitly set the --targetBinaryVersion parameter. Since build.gradle is a required file name, specifying the path to the containing folder or the full path to the file itself will both achieve the same effect.

code-push release-react MyApp-Android android -p "./foo/bar/"

code-push release-react MyApp-Android android -p "./foo/bar/build.gradle"

Plist file parameter (iOS only)

This specifies the relative path to the Info.plist file that the CLI should use when attempting to auto-detect the target binary version for the release. This parameter is only meant for advanced scenarios, since the CLI will automatically be able to find your Info.plist file in "standard" React Native projects, and you can use the --plistFilePrefix parameter in order to support per-environment plist files (e.g. STAGING-Info.plist). However, if your plist is located in an arbitrary location, that the CLI can't discover, then using this parameter allows you to continue releasing CodePush updates, without needing to explicitly set the --targetBinaryVersion parameter.

code-push release-react MyApp-iOS ios -p "./foo/bar/MyFile.plist"

NOTE: This parameter can be set using either --plistFile or -p

Private key path parameter

This parameter specifies a path to the private key file used to generate the signature of the update. If the private key path parameter is omitted, signature verification in the code-push plugin will be ignored.

Please refer to the Code Signing section for more details on the Code Signing feature.

• NOTE: This option is supported only for React Native applications on Android and iOS platforms.

Plist file prefix parameter (iOS only)

This specifies the file name prefix of the Info.plist file that that CLI should use when attempting to auto-detect the target binary version for the release. This can be useful if you've created per-environment plist files (e.g. DEV-Info.plist, STAGING-Info.plist), and you want to be able to release CodePush updates without needing to explicity set the --targetBinaryVersion parameter. By specifying a --plistFilePrefx, the CLI will look for a file named -Info.plist, instead of simply Info.plist (which is the default behavior), in the following locations: ./iosand ./ios/. If your plist file isn't located in either of those directories (e.g. your app is a native iOS app with embedded RN views), or uses an entirely different file naming convention, then consider using the --plistFileparameter.

# Auto-detect the target binary version of this release by looking up the

# app version within the STAGING-Info.plist file in either the ./ios or ./ios/ directories.

code-push release-react MyApp-iOS ios --pre "STAGING"

# Tell the CLI to use your dev plist (`DEV-Info.plist`).

# Note that the hyphen separator can be explicitly stated.

code-push release-react MyApp-iOS ios --pre "DEV-"

NOTE: This parameter can be set using either --plistFilePrefix or --pre

Sourcemap output parameter

This specifies the relative path to where the generated JS bundle's sourcemap file should be written. If left unspecified, sourcemaps will not be generated.

NOTE: This parameter can be set using either --sourcemapOutput or -s

Output directory parameter

This specifies the relative path to where the assets, JS bundle and sourcemap files should be written. If left unspecified, the assets, JS bundle and sourcemap will be copied to the /tmp/CodePush folder.

NOTE: All contents within specified folder will be deleted before copying

NOTE: This parameter can be set using either --outputDir or -o