The default name of a server bundle storage if omitted by the user in the configuration.

Parameter setting the minimum accepted server provided signature version.

The parameter must be prefixed by the repository identifier and storage name in the following format:

 <repo-id>.<storage-name>.<param>
 

The expected value of this parameter is an integer that specifies the minimum version.

By default, the verification mechanism only accepts the latest signature version for a downloaded bundle. Lowering the minimum accepted version may result in increased security risk as it may allow the loading of bundles that were signed with a compromised private key.

Newer releases of the Nest repository runtime will always use the signature version that is the most recent at the time of release. However, there may be cases when the signature version is increased by the server and older releases of the repository needs to be used by the developer. In these cases it is recommended to use the parameter to increase the minimum accepted signature version to the one that is provided by the server. This will prevent loading cached bundles that was signed with signature version more recent than the repository runtime release, but older than the version provided by the server.

In general, if the value of this parameter needs to be set below the version that is currently advertised by the server, that can signal serious issues in relation of security or internal implementation. Make sure to examine throughly the possible security consequences of such action.

Specifies if the server storage should operate in offline mode.

The parameter must be prefixed by the repository identifier and storage name in the following format:

 <repo-id>.<storage-name>.<param>
 

If the storage is set to operate in offline mode, any operations that require making network requests will result in OfflineStorageIOException. The storage is still safe to operate on locally cached bundles and indexes.

Specifies if an attempt should be made to avoid using network caches when making requests.

The parameter must be prefixed by the repository identifier and storage name in the following format:

 <repo-id>.<storage-name>.<param>
 

Various agents in the web can cache the results of requests from a given server. In some cases when using cached information from the server can cause build failures, as the build may expect the up-to-date information to properly finish.

These cases can happen if a package is just published, and the developer wants to use the latest version. However, the content delivery network will not yet serve the latest index files to the developer, as the cached copies hasn't expired yet. In these cases, the developer would need to wait out the cache expiration in order to be able to build their projects.

Specifying true to the value of this parameter will make the underlying storage issue requests to the servers that attempt to avoid retrieving the cached copies, and use the up-to-date indexes instead.

This parameter is mostly useful when running build on a CI, as in other environments the developer could manually force the index update if necessary.

In general, developers shouldn't use this parameter.

The default value of the parameter is based on the environment variables of the process. If there's an environment variable with CI=true, or TF_BUILD=true (values case insensitive), then the value of this parameter is true. Otherwise false.

(The environment variables are determined by known CI providers. While CI is supported by many, TF_BUILD is for Azure Pipelines.)

Note that caching the index files in the repository storage is unaffected by this parameter. If a non-expired cached index file is present in the repository storage, it will be used even if this parameter is set to true.

Specifies the secondary URL that can be used for load balancing when making network requests.

The parameter must be prefixed by the repository identifier and storage name in the following format:

 <repo-id>.<storage-name>.<param>
 

The secondary URL is used first to retrieve the bundle and task indexes from the server. As they might be often queried by clients, the secondary URL help taking the load off the primary server and lets it deal with other requests.

If the request to the secondary URL fails, the request will be tried again from the primary server.

Bundle downloads always use the primary URL.

The specified URL shouldn't have a slash separator at the end.

Secondary URL can be disabled by setting the empty or "null" value to it.

Specifies if the bundle signature verification should be disabled by the storage.

The parameter must be prefixed by the repository identifier and storage name in the following format:

 <repo-id>.<storage-name>.<param>
 

If the value of this parameter equals to "false" in a case-insensitive manner, the storage will not verify the downloaded bundle integrity, and will load them without verifying that they've been downloaded from the expected server.

In general, developers shouldn't disable the signature verification, as errors in the verification process either signal an internal implementation error, security breach, or other serious issue with the supporting environment. In case you feel the need to disable it, it is recommended to throughly examine the cause of error and verify that it is acceptable to impose the security risk caused by the lack of verification.

Specifies the server URL to be used by the storage view to access bundles.

The parameter must be prefixed by the repository identifier and storage name in the following format:

 <repo-id>.<storage-name>.<param>
 

In some case the secondary URL can take precedence when issuing requests for load balancing purposes.

The specified URL shouldn't have a slash separator at the end.

The default server URL that is used when no server URL parameter is specified.