Update: Artifacts retention policy

Posted on June 05, 2018

Since we announced an Artifacts retention policy on May 24th, we have heard your concerns and are making the following changes to the policy:

Best regards,
AppVeyor team

Updates to the AppVeyor Privacy Policy

Posted on May 25, 2018

As of May 25th, 2018, Appveyor Systems Inc. has updated its Privacy Policy to align with the General Data Protection Regulation (GDPR) that is in effect across the European Union.

For more information, please review our updated Privacy Policy.

Best regards,
AppVeyor team

Follow us on Twitter: @appveyor

Artifacts retention policy

Posted on May 24, 2018

Artifacts functionality has been working great for our customers since we introduced it in 2013, but we collected a huge amount of artifacts which are persisting in cloud storage.

Through talking to many customers we’ve identified that, after some period of time, storing old artifacts is unnecessary.

Indeed, once the app is deployed or a release package uploaded to external storage, its underlying artifact is usually no longer needed (except for those rare moments when some previous/stable release has to be re-deployed!)

To reduce AppVeyor hosting costs and eliminate any unnecessary waste of cloud resources we decided to introduce an artifacts retention policy.

The policy states that build artifacts and NuGet packages of paid accounts older than 6 months and free accounts older than 3 months will be permanently removed from AppVeyor artifact storage.

This policy will take effect on June 7, 2018.

If you have custom requirements please let us know and we’ll discuss your needs.

Best regards,
AppVeyor team

Follow us on Twitter: @appveyor

AppVeyor for Linux is generally available

Posted on May 15, 2018

Dear friends!

Just a short two months ago we announced the private beta of AppVeyor for Linux and we’ve been amazed by the amount of positive feedback we received and how high the demand was.

Thank you for your active participation! We managed to find and fix some issues, add missing pieces and make it ready for GA.

Starting today Ubuntu image will be available to all accounts, free and paid alike. The current working image users will see is based on Ubuntu 16.04 (Xenial Xerus) and a new one based on Ubuntu 18.04 (Bionic Beaver) will be added soon. We are committed to providing you the best and the latest Linux experience on our platform.

There is the Getting started with AppVeyor for Linux guide where you can also find a list of supported features and software pre-installed on the image.

Now AppVeyor is officially a multi platform CI service!

Enjoy your build!

Best regards,
AppVeyor team

Follow us on Twitter: @appveyor

Advanced build matrix configuration in AppVeyor

Posted on April 25, 2018

AppVeyor config evolution

AppVeyor configuration has grown incrementally more sophisiticated in order to accomodate not only a wide range of build requirements, but also AppVeyor’s feature set, and most pertinently to this post, the addition of linux build machines. This welcome addition to the AppVeyor platform means that users may want to build a cross-platform repository but may not want to manage separate configuration files. This is no longer a problem if we make use of the for: node in our appveyor configuration. This key was added previously to allow users to share common configuration between all branches while overriding parts of that configuration in specific branches. But along with the added features comes increased possibility of confusion regarding expected results of configuration.

The aim of this post is to give some more detail about advanced configuration options in which the potential for confusion is highest.

First, lets consider the following example:


# Configuration shared by all build jobs
platform:
  - x86
  - x64
configuration:
  - Debug
  - Release
environment:
  my_var1: value1
  my_var2: value2
test_script:
  - ps: Write-Host "common test script"
for:
  -
    branches:
      only:
        - master
    configuration: Release
    environment:
      my_var1: not-value1
      my_var3: new-value

  -
    branches:
      only:
        - /dev-.*/ #regular expressions can also be used to match several branches
      platform: Any CPU
      test_script:
        - echo "overriding common test script"

In the above configuration we see familiar keys being set that will be shared by all jobs calculated by the matrix. In the for: section we specify some overrides to those keys, and also some additions. If you’re not already familiar witht the rules for configuraion merging they can be found in the docs.

One potential source of confusion is understanding the number of jobs that will be calculated given the build matrix. In the example above, commits to unspecifed branches (i.e. not ‘master’ branches and not any branch matching the /dev-.*/ regexp) result in a build matrix calculated to have 4 jobs (2-configuration * 2-platform) Meanwhile, commits to master branch result in 2 jobs since the configuration key is overridden and set to a scalar value instead of a list (1-configuration * 2-platform). Ditto for commits to any branch matching the /dev-*/ regexp, except its the platform being overridden this time (2-configuration * 1-platform).

But the for: node functionality also allows the user to manipulate the build job matrix in order to specify platform specific configuration. Which is precisely where it serves cross-platform repos best.

For example:


version: 1.0.{build}

image:
  - Visual Studio 2017
  - Ubuntu
configuration:
  - Debug
  - Release
environment:
  my_var1: value1
  my_var2: value2
  matrix:
    - my_var3: value3
    - my_var4: value4
test_script:
  - ps: Write-Host "common test script"
matrix:
  - fast_finish: true
for:
  -
    matrix:
      only:
        - configuration: Release
          my_var3: value3
    environment:
      my_var1: overriden-value1
    platform: Any CPU # this setting is ignored
    test_script:
      - ps: write-host "for-matrix override test script 1"

  -
    matrix:
      only:
        - image: Ubuntu
          my_var4: value4
      pull_requests:
        do_not_increment_build_number: true # this setting is ignored
      allow_failures:
        - platform: x64 # this setting is ignored
    environment:
      my_var2: overridden-value2
    test_script:
      - sh: echo for-matrix override build script

Here we are able to create the desired matrix which consits of 8 jobs (2-image / 2-configuration / 2-environment variable groups), then in the for: node, specify special conditions for each job. Another important thing to note is the three matrix configuration keys within the for: node that are ignored. This makes sense intuitively, since these are meant to be, in a sense, ‘global’ configuration of the job matrix behaviour. A list of settings that are ignored can be found here

To keep your configuration code as slim as possible, its a good idea to utilize a ‘fall through’ as a default config. Consider this simple example:


version: 1.0.{build}

configuration:
  - Debug
  - Test

for:
  -
    matrix:
      only:
        - configuration: Debug
    build_script:
      - ps: "Debug build script"

  -
    matrix:
      only:
        - configuration: Test
    build_script:
      - echo "Test build script"

This configuration can be simplified to the following, allowing the ‘Debug’ configuration to be the default:


version: 1.0.{build}

configuration:
  - Debug
  - Test
build_script:
  - ps: "Debug build script"
for:
  -
    matrix:
      only:
        - configuration: Test
    build_script:
      - echo "Test build script"

AppVeyor’s new configuration capabilities give the user fine grained control allowing for virtually any imaginable configuration. But use these capabilities wisely and take a step back to make sure your build matrix is well formed and sensible.