Stream: committers
Topic: Getting a notification when a pull request is ready to merge
Jean Duteau (Sep 21 2021 at 20:06):
I have a pull request that I've been trying to merge for a day now. The first few commits had an error that a full build on my local computer didn't reveal but once I fixed that, it's been a process of having the pull request pipeline take its time to build, me coming back after a couple of hours to find out that some other pull request has been merged and I now need to re-merge and start over again. You can see four commits which is just merging the master branch into mine. The page does say that I'm receiving notifications, but I'm not sure where those notifications are going as I'm not receiving any emails about it. Is there something I haven't set up to receive notifications? And is there any way that we can streamline some of these checks so that it doesn't seemingly take hours?
Lloyd McKenzie (Sep 21 2021 at 23:12):
@Mark Iantorno
Mark Iantorno (Sep 22 2021 at 18:28):
- You can change your notification settings in Github to better suit your needs. This can range from emails notifying you of anything happening to a repo (don't do this, it's horrible), to notifying you when PRs you have submitted are commented on, or approved.
Mark Iantorno (Sep 22 2021 at 18:29):
- The build takes a while. I agree it's long, but right now, I'm not sure how to go about shortening that process because there's a lot going on.
Mark Iantorno (Sep 22 2021 at 18:30):
- There's nothing we can do about merge issues. That's just the nature of open source projects with lots of contributors. I understand it can be frustrating, but we need to rebuild everytime a merge is completed. This is done to ensure the main branches are working. If someone makes commits while you are waiting on your build...you will have to rebuild. The best way to avoid these kinds of issues is to keep PRs alive as short as you possibly can.
Grahame Grieve (Sep 22 2021 at 18:34):
you shouldn't get merge conflicts that often... what files are you getting them on?
Jean Duteau (Sep 22 2021 at 20:26):
i wasn't getting merge conflicts but rather a notification that the master had changed and needed to be merged into my branch. in a normal dev environment where pushing a change is seconds to at most a few minutes, that isn't painful. with our environment where the checks take 1/2 hour, that is painful.
Jean Duteau (Sep 22 2021 at 20:27):
my main problem appears to be no notifications. i'll look into that in GitHub to see what's going on there
I'm just wondering if we can apply more power to our build environments to get the build to take less time?
Mark Iantorno (Sep 23 2021 at 00:28):
You're going to get diminishing returns with that approach.
Mark Iantorno (Sep 23 2021 at 00:29):
Projects like this have a lot of things happening under the hood when they build, from external dependencies like terminologies, to actual copying/transferring of files.
Mark Iantorno (Sep 23 2021 at 00:29):
I can look into upping the power of the build machine, but I doubt that I can increase the speed that much.
Mark Iantorno (Sep 23 2021 at 00:30):
I have a powerful machine locally, and it still takes a while for me.
Mark Iantorno (Sep 23 2021 at 00:30):
The best option for you right now would be to configure your alerts to provide the info you want
Mark Iantorno (Sep 23 2021 at 00:30):
you will always need to rebuild on a merge though
Josh Mandel (Sep 23 2021 at 12:46):
https://mergequeue.com/ is an example of a tool designed to help with this problem and GitHub workflows. I have no experience with it, but I remember reading about it in a few months back.
Last updated: Apr 12 2022 at 19:14 UTC
