Posted on September 11, 2018
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
Posted on August 22, 2018
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
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
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
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