Shallow clone for Git repositories

Posted on June 04, 2014

AppVeyor runs every build on a new VM which is getting decommissioned right after the build finishes. The state between consequent builds of the same project is not preserved and every time a new build starts AppVeyor clones entire repository and then checkouts a specific commit. This becomes a challenge for very large repositories or repositories with long history as it takes a significant time to do a clone.

We introduced a new feature called “shallow clone” aiming to improve the situation with large repositories. It offers two options:

  1. Setting depth of git clone command
  2. Downloading repository as zipball using GitHub API

Setting depth of git clone command

By default AppVeyor clones entire repository with all the history. You can limit the number of last commits you’d like to clone. This feature works for Git repositories hosted at GitHub, BitBucket and Kiln. You can set clone depth on General tab of project settings:

Git clone depth

To set clone depth in appveyor.yml add the following in the root of config:

clone_depth: <number>

Note: Be aware that if you do a lot of commits producing queued builds and depth number is too small, git checkout operation following git clone can fail because the requested commit is not present in a cloned repository.

Downloading repository using GitHub API

As title says this option is specific to GitHub. It uses GitHub API to download specific commit of the repository as zip archive and then unpacks it on build worker machine. This feature works for regular commits, branch commits and pull requests.

You can enable this option through UI on General tab of project settings:

GitHub shallow clone

To enable it through appveyor.yml add the following in the root of config:

shallow_clone: true


Build worker improvements

Posted on April 23, 2014

While we are working on some new exciting stuff we continue improving things to make your AppVeyor experience even more smooth and streamlined. One of those recent improvements is a new build worker provisioning engine. Every build in AppVeyor runs on a dedicated virtual machine hosted in Microsoft Azure (yes, now it’s called “Microsoft Azure”). Azure is a great platform - their VMs are considerably faster than competitors’ and creation of a new VM is a blast (usually around 3 minutes). Simplified build flow is the following:

  • Build starts
  • A new VM is provisioning from “master” image (VHD) or being taken from “pre-heated” cache.
  • Build Agent installed on VM runs the build and “talks” to AppVeyor via Web Sockets (SignalR).
  • VM is being deleted after the build

How it was before

We were creating a new VM and then passing build details and starting Build Agent service through PowerShell remoting. That approach had a number of disadvantages:

  • Open WinRM endpoint accessible from the same network.
  • Constantly “pinging” starting up VM until it’s ready to accept WinRM connection. That solution had very high fault rate.
  • Once assigned to a build it was hard to switch build to another VM if the first one is unhealthy.

New approach

The new provisioning mechanism works “inside out”, i.e. Build Agent is started on VM boot and is “listening” for incoming command from AppVeyor using Web Sockets.


This new approach gives a number of benefits:

  • Build worker VM is completely isolated. It doesn’t have an external IP and no endpoints are configured - all inbound connections are prohibited. Even if you know its internal IP address (which is not a secret if you read NIC properties) you still can’t knock it as it sits in a separate private network (Azure cloud service).
  • No more starring at “Provisioning build worker…” or “pending” builds. Now it’s just “Queued” and then “Running”. We got some feedback that knowing VM is in provisioning state doesn’t feel very good and make customers nervous :)
  • If there is pre-heated VM available (we maintain between 3-4 VMs) your build starts almost instantly!
  • If there are no pre-heated VMs it would take around 3 minutes to provision new VM from scratch.
  • Whenever AppVeyor detects there is unhealthy VM worker it will re-schedule the build to another healthy instance, so generally it means being a bit longer in “Queued” state.

We also optimized worker “master” image (VHD) itself to make sure only minimum set of services is enabled to boot fast, eliminate lags and free more memory for your builds. Of course, you can still configure required services such as IIS and SQL Server databases.

Oh, and we introduced Windows Server 2012 R2 image which has almost identical configuration to Windows Server 2012 (except it doesn’t have VS 2010 installed).


Build worker improvements

Posted on March 31, 2014

When deploying web application to different environments you don’t want to re-build application package every time with different configurations, but you want to deploy the same package (artifact) with some environment-specific settings configured during deployment. When using Web Deploy the problem can be easily solved by Web Deploy parametrization.

Usage scenarios

Most common use cases for Web Deploy parametrization is updating node/attribute value in XML files or replacing a token in text files, for example:

  • appSettings in web.config
  • connection strings in web.config
  • WCF endpoints
  • Paths to log files
  • Database name in SQL install script


To enable Web Deploy parametrization add parameters.xml file in the root of your web application.


Parameters.xml contains the list of parameters required (or supported) by your Web Deploy package. In the example below we introduce two parameters - one to update path to log file in appSettings section of web.config and another one to set database name in SQL script.

Parameter element describes the name, default value and the places where and how this parameter must be applied.

Parameters.xml for our example:

<?xml version="1.0" encoding="utf-8" ?>
  <parameter name="LogsPath" defaultValue="logs">
    <parameterEntry kind="XmlFile" scope="\\web.config$" match="/configuration/appSettings/add[@key='LogsPath']/@value" />
  <parameter name="DatabaseName">
    <parameterEntry kind="TextFile" scope="\\Database\\install_db.sql$" match="@@database_name@@" />

When Web Deploy package is built you can open it in the explorer and see parameters.xml in the root:


Resulting parameters.xml combines your custom parameters and system ones such as IIS Web Application Name. You don’t have to set IIS Web Application Name parameter explicitly - AppVeyor does that for you.

Read more about defining parameters:

Setting parameters during deployment

Web Deploy provider in AppVeyor analyzes Web Deploy package and looks into environment variables to set parameter values with matching names.

When promoting specific build from Environment page you set variables on environment settings page:


When deploying during the build session environment variables are used instead. You can set build environment variables on Environment tab of project settings, appveyor.yml or programmatically during the build.


Variables defined during the build override those ones defined on Environment level.

Web Deploy parametrization is supported by Deployment Agent too when deploying from Web Deploy package.

Related articles:

AppVeyor 2.0 goes Live with the new pricing

Posted on March 26, 2014

I’m thrilled to announce that AppVeyor 2.0 officially goes Live and with the new aggressive pricing!

The New AppVeyor

After being almost two months in private and then public beta we finally upgraded production environment to AppVeyor 2.0 and developers truly love it!


Let me quickly recap what new features AppVeyor 2.0 brings to you:

  • Builds run on dedicated virtual machines
  • Project configuration in YAML (aka appveyor.yml)
  • Fine-grained control over build process
  • NuGet feeds hosting
  • Build matrix and parallel testing
  • Built-in deployment to multiple environments
  • Responsive, real-time UI
  • A lot of other improvements and fixes

The New Pricing

AppVeyor 2.0 moved from shared build farm to dedicated build machines. With that change it was obvious the current pricing scheme must be adjusted to justify new architecture. We received a signal from our customers that new plans felt pricey and not affordable for individual developers and small teams. This was not exactly our intention. We don’t want you to go through nightmare of installing TeamCity or Jenkins on Azure VM! :)

We want AppVeyor to be a great tool in the hands of every Windows developer! We listened to you and we revisited our plans before going Live to make sure AppVeyor pricing works for everyone.

New plans:

Open source Professional Premium Enterprise
FREE $39/month $79/month from $319/month
Unlimited public repositories 10 private repositories Unlimited private repositories Unlimited private repositories
1 concurrent job 1 concurrent job 2 concurrent jobs 4+ concurrent jobs
Forums support Email support Email support Priority technical support
- - - Phone/Skype support

Sign in to your existing account and start using AppVeyor for your next project!

Continuous Delivery of Windows Azure Cloud Services with AppVeyor CI

Posted on March 25, 2014


AppVeyor is Continuous Integration service for Windows developers to securely build and test code in parallel and deploy successful bits to on-premise or cloud environments.

In this tutorial we’ll guide you through the process of setting up a continuous delivery process for sample Azure Cloud Service (Azure CS) application starting from a code push to a repository and finishing with deployment of successful build to Azure.

Note to Global Windows Azure Bootcamp attendees

On Saturday, March 29, 2014 Global Windows Azure Bootcamp (GWAB) will take place in 141 locations across the globe. If you are not registered yet go find a location near you and do that. AppVeyor CI is one of the sponsors of this event and during that time we will be giving 2 free months with the purchase of any AppVeyor plan to all GWAB attendees.

AppVeyor CI has tight relationship with Windows Azure platform. First of all, AppVeyor is built for Azure and it uses Azure IaaS to run your builds on dedicated virtual machines. Second, AppVeyor provides complete Continuous Delivery cycle for Azure projects, i.e. building, testing, packaging and deploying your web applications and Azure Cloud Services. GWAB training classes is a wonderful place to try AppVeyor and setup super-simple continuous integration for your lab project.

Sample project on GitHub

We’ve created a simple Azure Cloud Service solution created in Visual Studio 2013 and consisting of a WebRole and xUnit test projects. You can find sample project repository on GitHub.


Note, that we don’t have “NuGet Package Restore” enabled for VS solution (no .nuget folder in repository). This is not necessary in AppVeyor environment - below you’ll see how to do that.

Sign up for AppVeyor account

If you don’t have AppVeyor account yet you should definitely get one! Go to and use “GitHub” button to sign up for Free plan which allows you building public repositories.


Add new project

Click New project and select GitHub repository:

New project

AppVeyor will automatically configure webhook for the repo to start a new build on every push.

Enable NuGet packages restore

To enable restore of NuGet packages during the build open project settings and add “nuget restore” command into before build script:

Project settings

Start new build

Run New build and see its progress in a real-time build console:

Build control

If you click Artifacts tab upon build completion you will see that AppVeyor automatically detected and packaged Azure Cloud Service project along with its configuration:

Build artifacts

In just a few minutes we have a pretty decent Continuous Integration process for our Azure Cloud Service!

Add new Azure Cloud Service environment

Now let’s deploy our “experimental” app to Windows Azure. Go to Environments and add new “Azure Cloud Service” environment:

Azure CS settings

The form requires 3 prerequisites:

  • Your Windows Azure account subscription details (Subscription ID and certificate).
  • Storage account for uploading Azure CS package (.cspkg file produced during the build) and then deploying from it.
  • Cloud Service to deploy to.

Subscription details

Download Azure account publishing profile and open it in text editor. Copy subscription ID and Base64 encoded subscription certificate.


Start new deployment

Now kick off new deployment of azure-cs-demo project to azure demo environment:

New deployment

Select the build to deploy:

New deployment select build

Observe the progress of deployment in the real-time console:

Azure deployment complete

Azure Cloud Service package from build 1.0.2 artifacts has been deployed and you can see the results in Azure Portal:

Azure portal deployment

Deploying as part of the build

Now after we triggered deployment manually from UI we’d like to completely automate the process and deploy during successful build. To setup deployment to azure demo environment open “Deployment” tab of project properties, add new “Environment” deployment and specify “azure demo” as environment name:

Project deployment

Done! Next time you push your changes into GitHub repository or start a new build on UI AppVeyor will build solution, run tests and deploy to Azure.