Pushing a feature branch schedules two builds

robert.jeppesen

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. #1 Posted by Feodor Fitsner Support staff on 24 Sep, 2015 06:34 PM

    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

    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. #3 Posted by Feodor Fitsner Support staff on 24 Sep, 2015 07:12 PM

    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

    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

    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. #6 Posted by Feodor Fitsner Support staff on 24 Sep, 2015 07:45 PM

    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

    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

    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. #9 Posted by Feodor Fitsner Support staff on 05 Oct, 2015 04:45 PM

    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

    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

    Hi,

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

    kind regards,
    James Swift

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

    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

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

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

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

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

    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

    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. #17 Posted by Feodor Fitsner Support staff on 25 Jun, 2016 05:38 PM

    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. #18 Posted by Feodor Fitsner Support staff on 28 Jun, 2016 05:14 AM

    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. #19 Posted by Feodor Fitsner Support staff on 28 Jun, 2016 05:16 AM

  20. #20 Posted by Chetan Kosrabe on 21 Jul, 2018 12:48 PM

    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

    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

    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

    Read this part of documentation.

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

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

    deploy:

      - provider: WebDeploy

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

        website: domainname

    But I can't deployment below server setting

    deploy:

      - 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

    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

    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 Support staff on 18 Sep, 2018 04:58 AM

  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

Generic

? 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

Recent Discussions