Each pull request would cause two CI runs
See https://ci.appveyor.com/project/zcbenz/atom-shell/history, in it each commit in pull request would emit two CI runs, one seems to be caused by GitHub generated merge commit.
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
Support Staff 1 Posted by Feodor Fitsner on 09 Aug, 2014 01:40 AM
Right, it builds the original "source" branch and then merged commit - there are two separate webhook events. Would you expect to build only merged one?
2 Posted by Cheng Zhao on 09 Aug, 2014 02:22 AM
I only expect the one that affects the CI state of GitHub's pull request (I'm not sure which one), the other one's result can only be seen on AppVeyor's page, which I think most GitHub users would not care. Building twice for one push also delays other pushes in queue greatly.
Travis CI seems to only build for the pull request's branch.
Support Staff 3 Posted by Feodor Fitsner on 09 Aug, 2014 02:39 AM
OK, that makes sense. I will give it a thought how to fix that.
4 Posted by its.the.doc on 19 May, 2015 02:06 AM
This is a must for me. I built my whole model around forking. I need to be able to only build the result of the pull requests merging into the repo or I can't use this tool. Any updates on this?
Support Staff 5 Posted by Feodor Fitsner on 19 May, 2015 02:14 AM
If you don't need building "base" repo on each pull request update (i.e. building virtual merge) then just disable "pull_request" event for AppVeyor webhook on GitHub.
6 Posted by its.the.doc on 19 May, 2015 02:16 AM
oh ok, fair enough. So then it'll just build the commit that results from the PR?
7 Posted by its.the.doc on 19 May, 2015 02:17 AM
Wait now, I actually have pull request unchecked.
8 Posted by its.the.doc on 19 May, 2015 02:18 AM
Can you just tell me specifically what I need?
Every time I accept a pull request, it builds twice.
I also have various other things checked related to deployment and I'm not sure how many of those things are even necessary.
Support Staff 9 Posted by Feodor Fitsner on 19 May, 2015 02:21 AM
What do you have in Recent deliveries when you do the merge.
- Feodor
10 Posted by its.the.doc on 19 May, 2015 02:26 AM
I have a release, various status's, and two pushes...one is the original commit, and one is a merge commit created from merging the fork in.
Support Staff 11 Posted by Feodor Fitsner on 19 May, 2015 02:27 AM
So, it does look correct from there?
12 Posted by its.the.doc on 19 May, 2015 02:29 AM
Well I'm not sure what you mean by correct exactly. I mean, if that's the intended behavior then yeah, everything looks good. No bad webhook calls or pull request calls.
I'd like to only build the result of the repository after the pull request is finished, not every commit involved.
Support Staff 13 Posted by Feodor Fitsner on 19 May, 2015 02:36 AM
If you have "pull request" event disabled on the webhook then there are at least two ways to prevent building unnecessary commits: a) setup branch filter, i.e. build
masteronly or b) add[skip ci]into commit message.14 Posted by its.the.doc on 19 May, 2015 02:40 AM
Alright, so the model I have, forks get merged into master, tagged, and build.
Then at a later stage I can choose if and where to deploy each version(outside of the build system).
So I don't have another branch to use. Branching happens pre pull request.
The second request, I'm not sure what you mean by that. I use that already, but are you saying I should ask each person who gives me a pull request to type in `[skip ci]` into their commit messages?
I'm not sure I follow your suggestions maybe.
Support Staff 15 Posted by Feodor Fitsner on 19 May, 2015 02:48 AM
Sorry, if I confused you. I just don't understand when/where do you get two builds? If you have a fork and "pull request" is disabled on its base repo how doing something in that fork could affect base repo?
Can you drop me a link to project build history please?
16 Posted by its.the.doc on 19 May, 2015 03:00 AM
yeah for sure.
https://ci.appveyor.com/project/KellyElton/octgn/history
and the two commits that trigger builds
https://github.com/iGemini/OCTGN/commit/d5e7647390abb440a4c93294226ed330e9313f69
https://github.com/octgn/OCTGN/commit/7bb4c5dd9313824ca14f6fbb5860c6698a138c83
Here are the webhooks in question as well https://gist.github.com/kellyelton/c7c0cfc637a06cbc76df
Support Staff 17 Posted by Feodor Fitsner on 19 May, 2015 03:32 AM
OK, one is a tag, but it's strange it wasn't recognized as a tag by AppVeyor. Do you have "Skip tags" set on General tab of project settings?
18 Posted by its.the.doc on 19 May, 2015 03:45 AM
Yeah I do "Do not build tags" is checked.
If it helps, the tag is generated by github when it creates a release.
Support Staff 19 Posted by Feodor Fitsner on 19 May, 2015 03:53 AM
I see regular commit produces two builds as well? https://ci.appveyor.com/project/KellyElton/octgn/history
That's really weird if so. Crazy idea - is there any chance you have two webhooks on that repo using the same webhook URL? :)
20 Posted by its.the.doc on 19 May, 2015 03:57 AM
Yeah, you know what, good call. I do lol
Support Staff 21 Posted by Feodor Fitsner on 19 May, 2015 03:59 AM
:) I'd believe in a miracle otherwise
22 Posted by its.the.doc on 19 May, 2015 04:01 AM
Haha. Sorry you spent time on that. I've been multitasking creating a new release system and pushing these builds out. Working on like 3 different code bases, my brains a little frazzled.
Thanks again for that.
Support Staff 23 Posted by Feodor Fitsner on 19 May, 2015 04:06 AM
Sure, no problem!
Ilya Finkelshteyn closed this discussion on 25 Aug, 2018 01:56 AM.