Split build status on GitHub PR
Appveyor builds "commit" and "pull request" per 1 GitHub PR.
But these builds use 1 GitHub status, "appveyor".
So I watch "Success on Appveyor", I don't know "Success with commit on Appveyor" or "Success with both commit and pull request on Appveyor".
Sometimes I merge a pull request during pull request build.
Would you split build status on GitHub PR like travis-ci?
Travis-ci splits them into travis-ci/push and travis-ci/pr.
E.g.
https://github.com/pandawing/node-run-yo/pull/33
Builds
https://ci.appveyor.com/project/sanemat/node-run-yo/build/1.0.55
https://ci.appveyor.com/project/sanemat/node-run-yo/build/1.0.56
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 Aug 27, 2015 @ 11:07 AM
Ah, I see what you mean. Interesting, didn't know it could be made like that. I've added a new issue: https://github.com/appveyor/ci/issues/384
2 Posted by Sanemat on Aug 27, 2015 @ 11:19 AM
Thanks!
3 Posted by Christian Mikke... on Nov 03, 2015 @ 08:10 PM
Hi
We are facing a situation where we are very dependend on the status link to point to the actual PR build and not the branch (commit) build.
We have tested and verified that sometimes the status link points to the branch (commit) build and sometimes the PR build.
Now on AV the PR is merged with latest master and for that reason we believe it is very, very important that the status link only points to the PR build.
Since we have an completely automated pipeline, this race condition means that we sometimes might end up deploying out of date binaries, which is bad.
Currently we have a "is the PR up to date with latest master check" which saves us, but we do believe that the status link should be "fixed" to only point at the PR build.
Today we find the PR correct build by fetching the build history using the API, filter for PR number and so forth. If we could trust the PR link we could drastically decrease the queries and the complexity of the pipeline and the performance.
In our eyes its a bug. But we do realize that this of course comes down to interpretation from both AV and GH :).
This was just our 5 cents :)
4 Posted by Pure Krome on Nov 12, 2015 @ 12:17 AM
Hi Feodor,
I just read your announcement email with the following:
Sepcifically, this bit: If you have protected GH branches checking AV status, please update them
Q:
1. What do you mean by this?
2. What would we have to update ?
When we create a new AV project, it auto adds the GH hooks. Do you mean we should manually update all these hooks, ourselves?
Support Staff 5 Posted by Feodor Fitsner on Nov 12, 2015 @ 12:21 AM
Look at the attached screenshot - if you've never set something like this then this announcement is not applicable to you :)
6 Posted by Pure Krome on Nov 12, 2015 @ 12:54 AM
oh wow! this is great! i didn't know this existed in GH.
i thought you ment protected GH branches was for private repo's. not this new GH thingy.
so if we decide to turn these features on (in GH) do we need to do manual stuff now ? or is this announcement only relevant to people who already have this turned on.
Support Staff 7 Posted by Feodor Fitsner on Nov 12, 2015 @ 01:00 AM
That's for people who already had this.
- Feodor
8 Posted by Pure Krome on Nov 12, 2015 @ 02:32 AM
cheers, ta!
9 Posted by tadej on Feb 13, 2016 @ 08:01 AM
I have problems properly configuring the new feature. I get split statuses but they should be selectable together like with travis (see attached screenshot). Otherwise, it breaks protected branch.
Is there any special configuration I need to do?
Support Staff 10 Posted by Feodor Fitsner on Feb 13, 2016 @ 03:49 PM
You can select "/pr" only.
-Feodor
11 Posted by tadej on Feb 13, 2016 @ 03:54 PM
Yes, but then I need to make pull requests for all changes.
Support Staff 12 Posted by Feodor Fitsner on Feb 13, 2016 @ 04:08 PM
Protected branches with status checks are supposed to work with PRs only: https://github.com/blog/2051-protected-branches-and-required-status-checks
It's not like "gated" checkins where regular push to branch can be rejected if the build didn't pass.
-Feodor
Ilya Finkelshteyn closed this discussion on Aug 25, 2018 @ 02:04 AM.