Pushing a feature branch schedules two builds

robert.jeppesen's Avatar


24 Sep, 2015 12:39 PM

When I push a feature branch, AppVeyor schedules two build, one for the feature branch, and one for master. Why is that, and how can I turn it off?

  1. Support Staff 1 Posted by Feodor Fitsner on 24 Sep, 2015 06:34 PM

    Feodor Fitsner's Avatar

    Is it because of pull requests?

    Check what's being sent to AppVeyor on GitHub webhook settings in "Recent deliveries".

  2. 2 Posted by robert.jeppesen on 24 Sep, 2015 07:09 PM

    robert.jeppesen's Avatar

    Thanks for your attention!

    Yes, it is because of a pull request. I see two deliveries with a few seconds between each. Two boxes are checked for events: 'Pull request' and 'Push'. Is my intuition correct that I should disable Pull request (because AppVeyor will be notified of the push anyway? And in that case, why didn't AppVeyor set it correctly when it created the webhook?

    I'm not sure what to look for in 'recent deliveries'.

  3. Support Staff 3 Posted by Feodor Fitsner on 24 Sep, 2015 07:12 PM

    Feodor Fitsner's Avatar

    For new webhooks AppVeyor sets both "push' and "pull request" events. Disable "pull request" if you wan't to build it only when it's merged into master.

  4. 4 Posted by robert.jeppesen on 24 Sep, 2015 07:15 PM

    robert.jeppesen's Avatar

    No, I want PR builds, for sure. I just don't want master to build every time a PR is updated. AppVeyor should be able to distinguish between these things?

  5. 5 Posted by robert.jeppesen on 24 Sep, 2015 07:19 PM

    robert.jeppesen's Avatar

    Maybe the confusion is this: I'm doing PR from the same repo, not a fork. I still think AppVeyor should be able to handle this.

  6. Support Staff 6 Posted by Feodor Fitsner on 24 Sep, 2015 07:45 PM

    Feodor Fitsner's Avatar

    Yeah, this might be a problem.

    Builds are triggered on:

    • push to branch
    • merge PR to branch
    • open PR
    • sync PR (when you do push to branch with open PR)
  7. 7 Posted by robert.jeppesen on 24 Sep, 2015 09:53 PM

    robert.jeppesen's Avatar

    Yes, the triggers you set are probably fine,
    but you need to inspect the incoming web hooks to see
    where a master build is not necessary. An optimization opportunity! :)

  8. 8 Posted by robert.jeppesen on 05 Oct, 2015 11:10 AM

    robert.jeppesen's Avatar

    The following should work better?
    When commit is within repo, build using 'Push to branch', ignore other triggers.
    When commit is in a different repo (PR from fork) build on Open/Sync PR only.

    Merge PR to branch is covered by the first rule.

  9. Support Staff 9 Posted by Feodor Fitsner on 05 Oct, 2015 04:45 PM

    Feodor Fitsner's Avatar

    Basically, this is how it currently works, but you also suggest to do not build PR if it's originating from the same repo?

  10. 10 Posted by robert.jeppesen on 06 Oct, 2015 06:40 AM

    robert.jeppesen's Avatar

    Yes. The 'Push to branch' trigger will take care of that when it's in the same repo.

    Also, 'Merge PR to branch' should never be needed, as 'Push to branch' will always take care of that, whether the PR originates from the same repo or not.

  11. 11 Posted by james on 11 May, 2016 12:20 PM

    james's Avatar


    we have exactly this problem.
    Is there a workaround or plans to change something?

    kind regards,
    James Swift

  12. Support Staff 12 Posted by Feodor Fitsner on 11 May, 2016 04:54 PM

    Feodor Fitsner's Avatar

    This is how GitHub works. When you have a branch and PR for that branch in the same repo GitHub calls webhook 2 times: 1st call when you push to branch and 2nd call when PR for that branch is synchronized.

  13. 13 Posted by Jay Bazuzi on 22 Jun, 2016 03:50 AM

    Jay Bazuzi's Avatar

    Aren't both for the same Commit ID? Can you dedup the webhook call on that?

  14. Support Staff 14 Posted by Feodor Fitsner on 22 Jun, 2016 08:13 PM

    Feodor Fitsner's Avatar

    Those are different commits. One is latest branch commit and another one master branch merged with branch.

  15. Support Staff 15 Posted by Feodor Fitsner on 22 Jun, 2016 08:15 PM

    Feodor Fitsner's Avatar

    I'm just thinking...what if we have an option saying "Do not build PRs from the same repository" - would that solve this issue? This case only branch builds would be started.

  16. 16 Posted by Michael Sarahan on 23 Jun, 2016 08:55 PM

    Michael Sarahan's Avatar

    IMHO, only the PR builds matter. People use branches on the main repo as collaboration points. We need CI for each push to a PR, but we don't really care about the branch itself.

  17. Support Staff 17 Posted by Feodor Fitsner on 25 Jun, 2016 05:38 PM

    Feodor Fitsner's Avatar

    Well, the implementation of such scenario could be tricky from performance perspective. Basically, on each push to a branch we should check if repository contains any open PRs with the branch.

  18. Support Staff 18 Posted by Feodor Fitsner on 28 Jun, 2016 05:14 AM

    Feodor Fitsner's Avatar

    OK, seems I've finally realized how to solve this issue (at least for GitHub which has extensive API)!

    There is an API for querying repository pull requests and filtering them by head branch: https://developer.github.com/v3/pulls/#list-pull-requests

    We can have another option on General tab of project settings, kind of Do not build feature branch if open PR exists (feel free to suggest a better, more clear name) which when enabled check if there are any opened PRs for push branch and if there any PRs build won't be started assuming there will be another build for PR(s).

  19. Support Staff 19 Posted by Feodor Fitsner on 28 Jun, 2016 05:16 AM

    Feodor Fitsner's Avatar
  20. 20 Posted by Chetan Kosrabe on 21 Jul, 2018 12:48 PM

    Chetan Kosrabe's Avatar

    When I committed features branch it is build failed its appear my appveyor.

    Please help me if any setting for Features branch failed not appear in my Appveyor .

  21. 21 Posted by Ilya Finkelshte... on 21 Jul, 2018 02:09 PM

    Ilya Finkelshteyn's Avatar

    Chetan Kosrabe: not sure we understand the problem. Do you need feature branches for not being built, you you want them for not setting build status on GitHub or other source control service? Or maybe something else... Please elaborate.

  22. 22 Posted by Chetan Kosrabe on 24 Jul, 2018 02:21 PM

    Chetan Kosrabe's Avatar

    Dear Ilya Finkelshteyn,

    Features branch committed on GitHub its build started CI its showing in CI.
    I want to don't show in CI features branch.

    [image: image.png]
    Currently Features branch committed showing my CI appveyor account I want
    to show only develop & master committed.

    Thanks & Regards
    Chetan Kosrabe
    System Administrator

  23. 23 Posted by Ilya Finkelshte... on 24 Jul, 2018 02:25 PM

    Ilya Finkelshteyn's Avatar

    Read this part of documentation.

  24. 24 Posted by Chetan Kosrabe on 01 Aug, 2018 08:27 PM

    Chetan Kosrabe's Avatar

    Hi sir,
    In Appveyor.yml file below server setting CI deployment success


      - provider: WebDeploy

        server: https://domainname:8172/msdeploy.axd?site=domainname

        website: domainname

    But I can't deployment below server setting


      - provider: WebDeploy

        server: https://publicip:8172/msdeploy.axd?site=Public ip:portnumber

        website: public ip :port number

    Have any setting CI for deployment public ip:port number

    Thanks & Regards
    Chetan Kosrabe

  25. 25 Posted by Ilya Finkelshte... on 01 Aug, 2018 08:46 PM

    Ilya Finkelshteyn's Avatar

    website setting in Web Deploy provider is for site name in IIS and has nothing to do with IP and/or port.

    If you have control over IIS server to which you are deploying, you can change website bindings there.

    Other option is to use deployment agent where you can control IP and port.

  26. 26 Posted by Bryan V on 18 Sep, 2018 12:25 AM

    Bryan V's Avatar

    I have enabled "Do not build feature branch if open PR exists" but I am still seeing both "branch" and "pr" builds for any push to a PR on the branch on the main repo. Any suggestions?

  27. 27 Posted by Owen McDonnell on 18 Sep, 2018 04:58 AM

    Owen McDonnell's Avatar
  28. Owen McDonnell closed this discussion on 18 Sep, 2018 04:58 AM.

Comments are currently closed for this discussion. You can start a new one.

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