Builds queued via GitHub Push build 2x

Paul Betts's Avatar

Paul Betts

13 Nov, 2014 12:48 AM

Every time we push on a branch, it also builds the master branch, which slows down builds quite a bit:

http://cl.ly/image/2j2H421U2m2Y

Any ideas on how we can get builds to only trigger for the changed branch?

Paul

  1. Support Staff 1 Posted by Feodor Fitsner on 13 Nov, 2014 12:58 AM

    Feodor Fitsner's Avatar

    Hi Paul,

    This is by design. Looking at screenshot I guess GitHub calls "synchronize" for Pull Requests based on the branch you are committing into. There are two webhook events coming from GH: "push" and "PR synchronize". You can check that on "Recent deliveries" of GH webhook settings.

  2. 2 Posted by paul.betts on 13 Nov, 2014 02:02 AM

    paul.betts's Avatar

    So, how do we fix this so that we only get one build and stop building master all the time?

    Paul


    Sent from Mailbox

  3. Support Staff 3 Posted by Feodor Fitsner on 13 Nov, 2014 02:29 AM

    Feodor Fitsner's Avatar

    I think there must be some option in AppVeyor switching PRs build behavior:

    1) Pushing to branch build branch only, but not depending PRs.
    2) Pushing to branch does not build branch, but builds depending PRs (seen request to have this logic a lot).
    3) Pushing to branch builds both branch and depending PRs (current default logic).

    These are my thoughts.

  4. 4 Posted by paul.betts on 13 Nov, 2014 06:45 PM

    paul.betts's Avatar

    Hey Feodor,

    I’m not sure that I grok “Pushing to branch does not build branch, but builds depending PRs” - are you saying that people will have multiple PRs whose head_ref is the same branch? I would think of this as an Evil scenario.

    At least with GitHub, I would build the branch whose contents have changed *only*. If you have a PR outstanding from the branch foo_bar => master, you don’t need to queue a build for that PR when master changes, because foo_bar doesn’t automatically change - it will only change when a developer runs “git merge” on the foo_bar branch. 

    I don’t believe you need to think about PRs at all in your build trigger logic, you should only think about branches changing, and setting the build status for the SHA1 that this branch now currently points to.

    Paul


    Sent from Mailbox

  5. Support Staff 5 Posted by Feodor Fitsner on 14 Nov, 2014 02:13 AM

    Feodor Fitsner's Avatar

    Well, there is quite an opposite suggestion in the adjacent thread: http://help.appveyor.com/discussions/suggestions/395-pick-particula... :)

    Re-reading your thread from the beginning gives me a hint that maybe simple ignoring of "synchronize" PR event would solve your issue. So, AV kicks off builds on PR "open" and branch "push" events. Right?

    Btw, I've switched your account to a new environment. You should see faster builds now.

  6. 6 Posted by paul.betts on 14 Nov, 2014 05:14 AM

    paul.betts's Avatar

    Hey Feodor,

    > Well, there is quite an opposite suggestion in the adjacent thread:

    I understand what this guy is proposing, but I think this guy is confused about how Git works. He’s proposing (I think!) that if either head_ref *or* base_ref change (i.e. “my-feature” or “master”), we should issue a build. 

    However, this doesn’t make sense in the context of Git - changing ‘master’ doesn’t directly affect “my-feature” at all! Only a developer running `git checkout my-feature && git merge master` would cause ‘my-feature’ to be combined with master, pushing to master only changes master. If a developer wants to find out if changes in master will affect ‘my-feature’, they should merge master into ‘my-feature’ themselves.

    The other path you *could* take, is make every PR build do an *implicit* merge from the base-branch before building. However, I’m really :-1: on this approach, because you’re not actually capturing the results of the code you pushed, you’re capturing the results of the code you pushed + some other unknown stuff. 

    > So, AV kicks off builds on PR "open" and branch "push" events. Right?

    Yep, I think that’s the best approach

    Paul


    Sent from Mailbox

  7. Support Staff 7 Posted by Feodor Fitsner on 14 Nov, 2014 06:51 PM

    Feodor Fitsner's Avatar

    OK, thanks for your input.

    I need sometime to "digest" this new information :)

  8. Ilya Finkelshteyn closed this discussion on 25 Aug, 2018 01:50 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