Most of our customers are already familiar with build matrix and commits filtering. Both concepts are common in the Continuous Integration world. The build matrix is used to run multiple scenarios as part of the same build (and against the same commit). Commits filtering allows a user to define conditions (for example commit message or file changed) under which the build should be skipped.

Now they come together (if needed). Also white/black-listing of branches and filtering of tags with skip_tags: true or skip_non_tags: true can be added to the mix.

Please check some examples (all scenarios are taken from real customer’s feature requests). Unrelated build configuration sections are omitted in favor of simplicity.

Scenario: normally, a build should run on Visual Studio 2017 and Ubuntu. However, when files changed only in docs folder and its subfolders, only Visual Studio 2017 build should be executed.

YAML:

image:
  - Visual Studio 2017
  - Ubuntu

for:
-
  matrix:
    except:
      - image: Visual Studio 2017
  skip_commits:
    files:
      - docs/**/*

Scenario: when a commit is tagged, only ReleaseAzure configuration should be built. Otherwise AppVeyor should start build for all 4 configurations.

YAML:

configuration:
  - ReleaseAzure
  - DebugAzure
  - ReleaseOnPrem
  - DebugOnPrem

for:
-
  matrix:
    except:
      - configuration: ReleaseAzure

  skip_tags: true

Scenario: the same configuration set as in the previous example, but here ReleaseAzure is skipped for all branches except master. All other configurations never skipped.

YAML:

configuration:
  - ReleaseAzure
  - DebugAzure
  - ReleaseOnPrem
  - DebugOnPrem

for:
-
  matrix:
    only:
      - configuration: ReleaseAzure

  branches:
    only:
    - master

Scenario: .csproj patching should happen only for tagged builds. For both tagged and non-tagged scenarios two build jobs should run: one Ubuntu1804 and one Visual Studio 2017.

YAML:

environment:
  matrix:
    - APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2017
      TAG_SCENARIO: false
    - APPVEYOR_BUILD_WORKER_IMAGE: Ubuntu1804
      TAG_SCENARIO: false

    - APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2017
      TAG_SCENARIO: true
    - APPVEYOR_BUILD_WORKER_IMAGE: Ubuntu1804
      TAG_SCENARIO: true

build_script:
  - echo common build script

for:
-
  # non-tagged scenario
  matrix:
    only:
      - TAG_SCENARIO: false

  skip_tags: true

-
  # tagged scenario
  matrix:
    only:
      - TAG_SCENARIO: true

  skip_non_tags: true

  dotnet_csproj:
    patch: true
    file: '**\*.csproj'
    version: '{version}'

Another good thing is that with commits filtering you are not blind. You do not need to open YAML and re-think why some build or build job has been skipped. Just open Events tab on your project page (https://ci.appveyor.com/project/{accountName}/{projectSlug}/events) and check respective warning!

Note that this feature is YAML only (not exposed in UI) now.

Best regards,
AppVeyor team

Pull Requests builds are useful in answering the question “What if this PR merged into target (base) branch”. Feature branch (other terms are source or head branch) build is not enough to answer this question, because while PR was developed some other commits could be made to the target (or base) branch.

During PR build AppVeyor merges PR with target (source or head) branch safely in transient build environment and runs required build scenario. Scenario itself can be altered in many ways for Pull Requests builds with project settings (like Pull Requests do not increment build number) and specific PR-related environment variables (like APPVEYOR_PULL_Requests_HEAD_REPO_BRANCH).

AppVeyor supports GitHub Pull Requests builds for years. Now we added Bitbucket Pull Requests support. For new projects it should work out-of-the box. For existing ones AppVeyor project webhook should be updated so the following Pull Requests events added: Created, Updated, Merged, Declined. To set this, navigate to your Bitbucket repository Settings tab, select Webhooks, find AppVeyor project webhook and press Edit.

If you do not need Bitbucket PR builds for new projects, uncheck those Webhook setting, so AppVeyor will not be notified of Bitbucket PR creations and changes.

Best regards,
AppVeyor team

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

• NuGet packages will not be deleted.
• Retention policy for artifacts will be 6 months for both open-source and private accounts without exclusions.
• Some projects have requirements to store artifacts beyond 6 months period. As they will not be stored on AppVeyor we have prepared two guides:
  • Copying artifacts of the finished builds to an external storage
  • Copying artifacts to an external storage during the build
• To give customers sufficient time to export important artifacts (older than 6 months) we are moving the effective date of the policy to June 17th, 2018.

Best regards,
AppVeyor team

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 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