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 27 Aug, 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 27 Aug, 2015 11:19 AM
Thanks!
3 Posted by Christian Mikke... on 03 Nov, 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 12 Nov, 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 12 Nov, 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 12 Nov, 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 12 Nov, 2015 01:00 AM
That's for people who already had this.
- Feodor
8 Posted by Pure Krome on 12 Nov, 2015 02:32 AM
cheers, ta!
9 Posted by tadej on 13 Feb, 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 13 Feb, 2016 03:49 PM
You can select "/pr" only.
-Feodor
11 Posted by tadej on 13 Feb, 2016 03:54 PM
Yes, but then I need to make pull requests for all changes.
Support Staff 12 Posted by Feodor Fitsner on 13 Feb, 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 25 Aug, 2018 02:04 AM.