Skip to content

Configurable settings

David Ebbo edited this page Sep 15, 2013 · 55 revisions

There are various things that you can configure using App Settings, which you can find on the Configure page in the Windows Azure portal.

Note that in addition to using App Settings, you can specify those settings in your .deployment file. This is useful if you want the setting to be part of your repository.

Repository and deployment related settings

Adding flags to the msbuild command line

Use this flag to add things at the end of the msbuild command line, such that it overrides any previous parts of the default command line.

e.g. to choose the Debug build configuration (default is Release), you could have:

SCM_BUILD_ARGS=/p:Configuration=Debug

Taking over the script generator command line

Kudu uses the azure site deploymentscript command described here to generate a deployment script. By default, it figures out what parameters to pass by looking at the files in the repo to determine the project type (e.g. Node, ASP.NET, ...).

But in some cases, you may want to override that and take control of the command line, which you can do using this setting.

e.g. to force your repo to be treated as a plain web site (no build), you can use:

SCM_SCRIPT_GENERATOR_ARGS=--basic -p FolderToDeploy

Changing the repo and deployment paths, and not using a repo at all

Please see Deploying inplace and without repository for information on using the SCM_REPOSITORY_PATH, SCM_NO_REPOSITORY, PROJECT and SCM_TARGET_PATH flags.

Using a git shallow clone in Continous Deployment scenarios

For large repos, you can make Kudu use a shallow clone when it clones your repo from GitHub or Bitbucket, which can save disk space. Shallow clones can be tricky, so make sure you understand what they are before using this. It is off by default. To turn it on:

SCM_USE_SHALLOW_CLONE=1

Diagnostic related settings

Changing the trace level

By default, it is set to 1, but you can get more tracing with higher values, up to 4. e.g.

SCM_TRACE_LEVEL=4

Changing the timeout before external commands are killed

By default, when your build process launches some command, it's allowed to run for up to 60 seconds without producing any output. If that is not long enough, you can make it longer, e.g. to make it 10 minutes:

SCM_COMMAND_IDLE_TIMEOUT=600

Changing the timeout of the log streaming feature

When using the log streaming feature, by default it times out after 30 minutes of inactivity. To change it to 15 minutes (unit is seconds):

SCM_LOGSTREAM_TIMEOUT=900

Runtime settings

The following settings must be set in the Azure App Settings, and cannot be overridden in the .deployment file (since they are not deployment settings)

Change the Node version

Used the change the version of Node that is used by default

WEBSITE_NODE_DEFAULT_VERSION=0.10.5

Enable the use of private Site Extensions on a site

WEBSITE_PRIVATE_EXTENSIONS=1

Diagnostics related settings

The name (or relative path to the LogDirectory) of the file where internal errors are logged, for troubleshooting the listener:

DIAGNOSTICS_LASTRESORTFILE=logging-errors.txt

The settings file, relative to the web app root:

DIAGNOSTICS_LOGGINGSETTINGSFILE=..\diagnostics\settings.json

The log folder, relative to the web app root:

DIAGNOSTICS_TEXTTRACELOGDIRECTORY=..\..\LogFiles\Application

Maximum size of the log file (Default: 128 kb):

DIAGNOSTICS_TEXTTRACEMAXLOGFILESIZEBYTES=200000

Maximum size of the log folder (Default: 1 MB):

DIAGNOSTICS_TEXTTRACEMAXLOGFOLDERSIZEBYTES=2000000

Clone this wiki locally