<commit_before>---
layout: docs
title: Build configuration
---

# Build configuration

* [Build environment](#build-environment)
* [Build pipeline](#build-pipeline)
* [Configuring build](#configuring-build)
* [Build versioning](#build-versioning)
* [AssemblyInfo patching](#assemblyinfo-patching)
* [Clone directory](#clone-directory)
* [Environment variables](#environment-variables)
* [Secure variables](#secure-variables)
* [Script blocks](#script-blocks)
* [Installing software](#installing-software)
* [Hosts entries](#hosts)
* [Build matrix](#build-matrix)
* [Scheduled builds](#scheduled-builds)
* [Build queue](#build-queue)

<a id="build-environment"></a>
## Build environment

Every build runs on a fresh virtual machine which is not shared with other builds and the state of which is not preserved between consequent builds. After the build is finished its virtual machine is decommissioned.

Free plans run builds on VM instances with 1 virtual core, 1.75 GB of memory and 127 GB of disk space (Windows Azure "Small").

Paid plans run on a dedicated hardware with faster CPUs and SSD drives. Each VM has 2 virtual cores, 1.5 GB of memory and 127 GB disk drives (with about 50 GB free).

IP addresses assigned to build workers:

    172.16.58.3-190    (172.16.58.3/28)
    192.168.127.12-158    (192.168.127.12/29)
    192.168.3.11-28      (172.16.17.32/28)
    192.168.3.11-166   (172.16.17.32/29)


<a id="build-pipeline"></a>
## Build pipeline

Every build goes through the following steps:

1. Run `init` scripts
2. **Clone** repository into clone folder

    * Checkout build commit
    * `cd` to clone folder

3. Run `install` scripts
4. Patch `AssemblyInfo` files
5. Modify `hosts` files
6. Start services
7. **Build**

    * Run `before_build` scripts
    * Run msbuild
    * Run `after_build` scripts

8. **Test**

    * Run `before_test` scripts
    * Discover and run tests
    * Run `after_test` scripts

9. Call `build_success` webhooks
10. **Package** artifacts
11. **Deployment**

    * Run `before_deploy` scripts
    * Run all configured deployments
    * Run `after_deploy` scripts

12. For successful builds:

    * Call `deployment_success` webhooks
    * Run `on_success` scripts

13. For failed builds:

    * Call `build_failure` webhooks
    * Call `deployment_failure` webhooks
    * Run `on_failure` scripts

14. For both successful and failed builds:
    * Call `on_finish` scripts

### Time limitations

Free, Professional and Premium plans have a hard quota of 30 minutes on build execution time. Enterprise plans allow 50 minutes per build job.


<a id="configuring-build"></a>
## Configuring build

Project builds can be configured by either `appveyor.yml` or on the user interface.

Each method has pros and cons. Via the User interface one can control every aspect of the build process without ever touching the repository. On the other hand, YAML may seem more sophisticated and familiar for those coming from a Linux platform. Another thing to consider is that when you fork/clone a project with its configuration stored in `appveyor.yml`, you simply add a new project in AppVeyor referencing repo and you are good to go.

> It's worth noticing that both `appveyor.yml` and UI configuration are mutually exclusive. It's always either YAML or UI - the settings from each are not merged. If you have `appveyor.yml` in your repo it will override all settings made on the UI unless explicitly disabled by **Ignore appveyor.yml**.


### appveyor.yml<commit_msg>Added a note about merging YAML and UI variables.<commit_after>---
layout: docs
title: Build configuration
---

# Build configuration

* [Build environment](#build-environment)
* [Build pipeline](#build-pipeline)
* [Configuring build](#configuring-build)
* [Build versioning](#build-versioning)
* [AssemblyInfo patching](#assemblyinfo-patching)
* [Clone directory](#clone-directory)
* [Environment variables](#environment-variables)
* [Secure variables](#secure-variables)
* [Script blocks](#script-blocks)
* [Installing software](#installing-software)
* [Hosts entries](#hosts)
* [Build matrix](#build-matrix)
* [Scheduled builds](#scheduled-builds)
* [Build queue](#build-queue)

<a id="build-environment"></a>
## Build environment

Every build runs on a fresh virtual machine which is not shared with other builds and the state of which is not preserved between consequent builds. After the build is finished its virtual machine is decommissioned.

Free plans run builds on VM instances with 1 virtual core, 1.75 GB of memory and 127 GB of disk space (Windows Azure "Small").

Paid plans run on a dedicated hardware with faster CPUs and SSD drives. Each VM has 2 virtual cores, 1.5 GB of memory and 127 GB disk drives (with about 50 GB free).

IP addresses assigned to build workers:

    172.16.58.3-190    (172.16.58.3/28)
    192.168.127.12-158    (192.168.127.12/29)
    192.168.3.11-28      (172.16.17.32/28)
    192.168.3.11-166   (172.16.17.32/29)


<a id="build-pipeline"></a>
## Build pipeline

Every build goes through the following steps:

1. Run `init` scripts
2. **Clone** repository into clone folder

    * Checkout build commit
    * `cd` to clone folder

3. Run `install` scripts
4. Patch `AssemblyInfo` files
5. Modify `hosts` files
6. Start services
7. **Build**

    * Run `before_build` scripts
    * Run msbuild
    * Run `after_build` scripts

8. **Test**

    * Run `before_test` scripts
    * Discover and run tests
    * Run `after_test` scripts

9. Call `build_success` webhooks
10. **Package** artifacts
11. **Deployment**

    * Run `before_deploy` scripts
    * Run all configured deployments
    * Run `after_deploy` scripts

12. For successful builds:

    * Call `deployment_success` webhooks
    * Run `on_success` scripts

13. For failed builds:

    * Call `build_failure` webhooks
    * Call `deployment_failure` webhooks
    * Run `on_failure` scripts

14. For both successful and failed builds:
    * Call `on_finish` scripts

### Time limitations

Free, Professional and Premium plans have a hard quota of 30 minutes on build execution time. Enterprise plans allow 50 minutes per build job.


<a id="configuring-build"></a>
## Configuring build

Project builds can be configured by either `appveyor.yml` or on the user interface.

Each method has pros and cons. Via the User interface one can control every aspect of the build process without ever touching the repository. On the other hand, YAML may seem more sophisticated and familiar for those coming from a Linux platform. Another thing to consider is that when you fork/clone a project with its configuration stored in `appveyor.yml`, you simply add a new project in AppVeyor referencing repo and you are good to go.

> It's worth noticing that both `appveyor.yml` and UI configuration are mutually exclusive. It's always either YAML or UI - the settings from each are not merged. If you have `appveyor.yml` in your repo it will override all settings made on the UI unless explicitly disabled by **Ignore appveyor.yml**. The only exceptions are environment variables and notification settings. Environment variables defined on UI are getting merged with those ones defined in `appveyor.yml`. Variable values with the same names are getting overridden with values from UI.


### appveyor.yml
{'fraction_non_alphanumeric': 0.09175696063640104, 'fraction_numerical': 0.03593471403099712, 'mean_word_length': 4.063888888888889, 'pattern_counts': {'":': 0, '<': 15, '<?xml version=': 0, '>': 17, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 16, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '918605', 'n_tokens_mistral': 2254, 'n_tokens_neox': 2006, 'n_words': 903}