How to conditionally skip some matrix builds for the PRs merge-into-branch builds?

danny's Avatar


18 Mar, 2019 12:08 PM

My builds rely on Dart SDKs, and Visual Studio Code. To catch if changes to either of those break my code, I run my tests against both of them:


Additionally, on the master branch I run combinations of Stable/Dev (so that if changes to one of them do get broken, it's clearer whether it's the dev version of Dart, or the dev version of VS Code):

        - master

This mostly works great. My builds for branches only run the stable/stable and dev/dev builds. However, for PRs, there are two builds kicked off - one for the PR branch, and another for that branch merged into master. Because branch=master is true for that merge branch, it means the Dev/Stable and Stable/Dev builds also run for that.

What can I add to the for: block above to have those matrix configs only apply when branch=master and it's not a pr-merged-with-master build?

  1. Support Staff 1 Posted by Owen McDonnell on 18 Mar, 2019 02:05 PM

    Owen McDonnell's Avatar

    I'm not sure how it may affect the rest of your config, but you could check Do not build on "Pull request" events in UI settings (this setting is only available from UI, and will be respected even if you use yaml file)?

  2. 2 Posted by danny on 18 Mar, 2019 02:16 PM

    danny's Avatar

    I don't want to prevent the whole build - I just only want 2 of the 4 build types to run for these builds. The Dev/Stable and Stable/Dev variations in matrix are essentially "optional builds" that I only want to run for real pushes (as opposed to the synthentic merge builds created from a PR by GitHub).

    Essentially, I want to add a condition similar to the `branches: only: - master` above that basically means "is not a PR".

    Hope that makes sense!

  3. Support Staff 3 Posted by Owen McDonnell on 18 Mar, 2019 05:52 PM

    Owen McDonnell's Avatar

    There are a couple possible solutions with different pros/cons.

    If you are looking to avoid extraneous use of concurrent jobs you could forcibly terminate a build based on a script something like this at init: stage...

    ps: if ($env:APPVEYOR_PULL_REQUEST_NUMBER -gt 0 -and ($env:ONLY_RUN_DART_VERSION -eq "DEV" -or $env:ONLY_RUN_CODE_VERSION -eq DEV) ) {Exit-AppveyorBuild}
    Alternatively, if you are more interested in clean build history than not blocking jobs, you could create a separate project for those specific build matrix dimensions in which pull request events are disabled.
  4. 4 Posted by danny on 18 Mar, 2019 07:05 PM

    danny's Avatar

    As long as it doesn't result in failed builds, that `init` option is probably fine. I'll give it a go tomorrow - thanks!

  5. 5 Posted by danny on 19 Mar, 2019 08:44 AM

    danny's Avatar

    The init script appears to have worked great! The condition I wanted was:


    Since I wanted Dev/Dev and Stable/Stable to run. The builds are quit early and marked green :-)

    It'd be nice if there was a way to include this in the `for` block, in the same way you can control branches, do a "is not PR" filter if you're looking for work to do, but this fix is fine for what I wanted (which is really just to speed up my builds - they're quite slow and often end up in a big queue when I'm pushing things to several branches).


  6. Support Staff 6 Posted by Owen McDonnell on 19 Mar, 2019 06:21 PM

    Owen McDonnell's Avatar

    Thanks for the update. Feel free to make a feature request if you think it's a common enough use case.

Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:


Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac