Posted on March 06, 2018
Dear AppVeyor friends,
We’d like to thank you for building and testing your awesome Windows applications on AppVeyor! Your trust and support have always been driving us to evolve the service.
Today, we want to give you twice as much value with the addition of Linux platform! Now you can run your builds side-by-side on Ubuntu and Windows images.
It’s not a weekend project and we have a strong commitment to make AppVeyor a full-featured cross platform solution.
Evolved from our Windows offering, AppVeyor for Linux has some unique features:
sudoaccess to VM running build.
AppVeyor for Linux is currently in private beta, available by request. To participate in beta just reply to this message and provide your AppVeyor account details.
We have prepared a Getting started with AppVeyor for Linux guide where you can also find a list of supported features and pre-installed software.
Perhaps what is most amazing about the addition of this new Linux platform is that it will not affect our low pricing! Once out of beta, the new Ubuntu image will be available to every account, free or paid. However, Premium accounts with two or more concurrent jobs will benefit the most as they will be able to run their tests on two platforms simultaneously.
Follow us on Twitter: @appveyor
Posted on November 08, 2017
Builds run on schedule is a feature we’ve been offering since early days of AppVeyor. It works great for many private and OSS projects. However, over the time we started noticing that there are a lot of “abandoned” projects with maintainers once configured scheduled builds and then leaving them running for the same commit over and over again.
Starting today we are making scheduled builds an optional feature for free accounts which is disabled by default. Paid accounts will continue to have scheduled builds enabled by default.
If you are the maintainer of OSS project and your CI workflow requires scheduled builds contact AppVeyor team and briefly describe your needs to request this feature.
Follow us on Twitter: @appveyor
Posted on October 03, 2017
Today we are excited to announce immediate availability of AppVeyor Enterprise!
AppVeyor is being used by more than 50,000 developers and we’ve run 10,000,000+ builds. As many companies had been asking about the possibility of installing AppVeyor behind their firewalls we started looking into just that. AppVeyor was originally born as a cloud product and tied to Azure. During the past few years we’ve been refactoring and maturing the AppVeyor codebase to fit into an on-premise scenario, and it is finally here!
AppVeyor Enterprise benefits:
Clean isolated environment for every build. Each new build runs on a new pristine VM which is immediately deleted afterwards to keep your costs low. This is the feature that we’ve been evangelizing from the very beginning and which we think sets AppVeyor apart from other products.
Multiple clouds to provision build VMs. You can run builds in different clouds (Azure, Google, Amazon) or on a Hyper-V server. On ci.appveyor.com we’re distributing load between clouds and we have multi-zone failover configurations and switch cloud providers depending on build image. All this cool stuff is available to you now!
Works with any language/stack. You can easily configure build projects with versioned AppVeyor YAML. We’ve gathered so much knowledge from the AppVeyor community and now you can use all these recipes for your own projects!
Works with your source control. AppVeyor can fetch the code from GitHub, Bitbucket, GitLab, Kiln or any other regular Git, Mercurial or SVN repository.
Built-in deployment. With AppVeyor Enterprise you can build once and promote the same package to multiple deployment environments. Hosted AppVeyor has been used by customers more than 1,200,000 times to deploy their applications.
Pricing for the cloud era. With AppVeyor Enterprise you can complete your test suite faster and with less cost. You get unlimited clouds, unlimited concurrent jobs, unlimited build and deploy agents. Pricing is based on the size of your team and starts from $300/month per 10 users.
Request your free trial of AppVeyor Enterprise today!
Follow us on Twitter: @appveyor
Posted on August 01, 2017
There are two options to have branch-specific configuration with
appveyor.ymlinto each branch with branch-specific settings.
appveyor.ymlhas a list of configurations for different branches.
The problem with 1st approach is merging as you are overriding
appveyor.yml in the base branch with one from the branch being merged.
2nd approach requires
appveyor.yml of the following format:
# 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
While this approach works great in the most cases there is one incovenience though - with large configuration and many branches
appveyor.yml becomes really unmanageable and error-prone as you have to repeat (copy-paste) entire configuration for every branch.
We just deployed an update to AppVeyor that allows sharing common configuration between branches in a single
There is new
for node with a list of branch-specific configurations overriding common configuration defined on the top most level, for example:
# common configuration for ALL branches environment: MY_VAR1: value-A init: - do_something_on_init.cmd install: - do_something_on_install.cmd configuration: Debug # here we are going to override common configuration for: # override settings for `master` branch - branches: only: - master configuration: Release deploy: provider: FTP ... # override settings for `dev-*` branches - branches: only: - /dev-.*/ environment: MY_VAR2: value-B deploy: provider: Local ...
In the example above we define
install sections for all branches as well as stating that default
Debug. Then, for
master branch we override default settings by changing
Release and adding deployment with
FTP provider. For
dev-* branches we define a second environment variable
MY_VAR2 and enable deployment to
Configuration merging rules:
platform, etc. defined on branch level override default ones;
test_script, etc. defined on branch level override default ones;
environmentsections are merged (new) and overridden (existing);
notificationssection can be either overridden or extended.
For example, consider the following configuration:
artifacts: - path: bin deploy: - provider: Local ... notifications: - provider: Email ... for: branches: only: - master artifacts: - path: docs deploy: off notifications: provider: Slack ...
In the example above we do the following:
masterbranch we adding
docsfolder to artifacts definition, so both
docsfolders collected. Both default and branch-specific collections were merged.
masterbranch we disable any deployment.
noneon branch-level clears default collection.
masterbranch we replace all notifications on default level with a single
Follow us on Twitter: @appveyor
Posted on March 17, 2017
CodeCov visualises code coverage and can enforce standards via GitHub and AppVeyor. More information is available on CodeCov.io.
This post is written from the point of view of someone (me) who is already proficient in C# and unit testing, but was new to AppVeyor and integrating CodeCov with GitHub.
If you are new to GitHub, see this getting started guide, otherwise simply create a new repo (YourRepositoryName from now on) and git clone it somewhere convenient.
In my version of Visual Studio (Community 2015), you can do this by clicking on “File - New - Project” on the main menu, then “Class Library” from “Templates - Visual C#”. Give it a interesting name, which I will assume to be YourSUTProjectName for the rest of this post.
Repeat this for the test project, which I will assume to be YourTestProjectName.
xunit.runner.console nuget packages to your test project.
Add an XUnit test to YourTestProjectName and the corresponding thing under test to YourSUTProjectName, or copy and paste mine.
Run this test to make sure it passes.
You will need to link an AppVeyor account to your GitHub one, so let’s do that:
Now Log in to AppVeyor.com, probably using your GitHub account
When working with AppVeyor, it always makes sense to test on your own computer first. The feedback is immediate and you iterate very quickly. It takes a lot longer to modify the appveyor.yml file, push it and wait for a build to go through. Also, if it works locally but doesn’t work on AppVeyor, you know the problem is a configuration difference between your computer and the AppVeyor environment (eg a different version of msbuild).
However, this step is not required, so skip to “Run Coverage Analysis on AppVeyor” if you wish.
CodeCov.io is a tool for visualising and integrating coverage data, which we need to create. We will use OpenCover to do this.
OpenCover nuget package to the solution (which will install OpenCover.Console.exe, probably in packages\OpenCover.4.6.519\tools) and then run the following in a command window.
packages\OpenCover.4.6.519\tools\OpenCover.Console.exe -register:user -target:"packages\xunit.runner.console.2.2.0\tools\xunit.console.x86.exe" -targetargs:"YourTestDLL -noshadow" -output:".\coverage.xml" -filter:"+[YourSUTNamepace*]* -[YourTestNamespace*]*"
Run the following on a PowerShell command line. This talks to CodeCov and downloads a bash script to upload the coverage.
Invoke-WebRequest -Uri 'https://codecov.io/bash' -OutFile codecov.sh
Then you can run the following in a Bash command line (You can use
Git Bash on Windows). YourUploadToken is the CodeCov token that you took a note of earlier, or available on the project settings page on CodeCov (eg
codecov.sh -f "coverage.xml" -t YourUploadToken
The output will show a url with the results (eg
Now that the coverage upload is working locally, we can run it on AppVeyor.
Add and commit an
appveyor.yml file to the root of the repository as below.
before_build: - nuget restore build_script: - msbuild /verbosity:quiet "YourSolution" test_script: - .\packages\OpenCover.4.6.519\tools\OpenCover.Console.exe -register:user -target:"%xunit20%\xunit.console.x86.exe" -targetargs:"YourTestDll -noshadow" -output:"coverage.xml" -filter:"+[YourSUTNamepace*]* -[YourTestNamespace*]*" after_test: - ps: | $env:PATH = 'C:\msys64\usr\bin;' + $env:PATH Invoke-WebRequest -Uri 'https://codecov.io/bash' -OutFile codecov.sh bash codecov.sh -f "coverage.xml" -t YourUploadToken
There are various badges and graphs available. Click on your project in CodeCov, then “Settings” and “Badge” (eg
https://codecov.io/gh/YourGitHubUserName/YourRepositoryName/settings/badge) to see what’s available.
Copy and paste a code snippet from this in to your README.md, such as this one .
CodeCov automatically integrates with GitHub pull requests (as long as you signed up to CodeCov via your GitHub account) which you can see on this pull request.
It will show some statistics, such as the increase or decrease in coverage, and by default will fail the build if coverage decreases. You can configure this with a ‘codecov.yml’ file in the root of your repository.
There is a CodeCov browser plugin, for all reputable browsers, that adds coverage when browsing GitHub.com. Code is highlighted in red / green, and a coverage percentage is shown.
It can be difficult keeping control of test coverage for a project, especially with distributed and transient team structures. The combination of GitHub, AppVeyor OpenCover and CodeCov make it very easy to visualise the coverage, and allow you to enforce standards to ensure that it improves over time.