Posted on July 23, 2014
If you use git flow you may want to have a different build configuration (e.g. deploying to a different environment) in a feature branch. Changing
appveyor.yml in a feature branch becomes an issue when you merge it into master overriding
appveyor.yml and breaking master builds.
To solve this problem AppVeyor allows having multiple per-branch configurations in a single
Multiple configurations are defined as a list with
branches section in every item that:
# configuration for "master" branch # build in Release mode and deploy to Azure - branches: only: - master configuration: Release deploy: provider: AzureCS ... # configuration for all branches starting from "dev-" # build in Debug mode and deploy locally for testing - branches: only: - /dev-.*/ configuration: Debug deploy: provider: Local ... # "fall back" configuration for all other branches # no "branches" section defined # do not deploy at all - configuration: Debug
Unlike white- and blacklisting
branches section here works like a selector, not a filter. Configuration selection algorithm is the following:
branches/onlysection defined. If branch is found in configuration’s
onlysection use this configuration.
branches/exceptsection defined. If branch is NOT found in configuration’s
exceptsection use this configuration.
branchessection. If such configuration is found use it.
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:
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:
To set clone depth in
appveyor.yml add the following in the root of config:
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.
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:
To enable it through
appveyor.yml add the following in the root of config:
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:
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:
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:
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).
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.
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:
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" ?> <parameters> <parameter name="LogsPath" defaultValue="logs"> <parameterEntry kind="XmlFile" scope="\\web.config$" match="/configuration/appSettings/add[@key='LogsPath']/@value" /> </parameter> <parameter name="DatabaseName"> <parameterEntry kind="TextFile" scope="\\Database\\install_db.sql$" match="@@database_name@@" /> </parameter>
When Web Deploy package is built you can open it in the explorer and see
parameters.xml in the root:
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: https://technet.microsoft.com/en-us/library/dd569084(v=ws.10).aspx
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.
Posted on March 26, 2014
I’m thrilled to announce that AppVeyor 2.0 officially goes Live and with the new aggressive pricing!
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:
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.
|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|
Sign in to your existing account and start using AppVeyor for your next project!