Re: [Pulp-dev] PR merging

2020-10-23 Thread David Davis
I wasn't able to get to this this week. Will send out an email next week with another date. David On Tue, Oct 13, 2020 at 12:52 PM David Davis wrote: > During the pulpcore team meeting today there was a desire to move forward > with auto-merging pulpcore PRs. This would mean automatically

Re: [Pulp-dev] PR merging

2020-10-13 Thread David Davis
During the pulpcore team meeting today there was a desire to move forward with auto-merging pulpcore PRs. This would mean automatically merging of pulpcore PRs that have all the necessary approvals (2), tests passing, no changes requested, and are not draft PRs. Here is the pulp-ci PR again for

Re: [Pulp-dev] PR merging

2020-10-01 Thread Brian Bouterse
On Thu, Oct 1, 2020 at 7:35 AM Ina Panova wrote: > > > > Regards, > > Ina Panova > Senior Software Engineer| Pulp| Red Hat Inc. > > "Do not go where the path may lead, > go instead where there is no path and leave a trail." > > > On Wed, Sep 30, 2020 at 2:38 PM David Davis wrote: > >>

Re: [Pulp-dev] PR merging

2020-10-01 Thread Ina Panova
Regards, Ina Panova Senior Software Engineer| Pulp| Red Hat Inc. "Do not go where the path may lead, go instead where there is no path and leave a trail." On Wed, Sep 30, 2020 at 2:38 PM David Davis wrote: > I am also concerned about the lack of human involvement and the potential

Re: [Pulp-dev] PR merging

2020-09-30 Thread Daniel Alley
I used it recently (last week). Agreed that it is not commonly needed and especially not in pulpcore though. On Wed, Sep 30, 2020 at 8:52 AM Matthias Dellweg wrote: > > > On Wed, Sep 30, 2020 at 2:37 PM David Davis wrote: > >> I am also concerned about the lack of human involvement and the

Re: [Pulp-dev] PR merging

2020-09-30 Thread Matthias Dellweg
On Wed, Sep 30, 2020 at 2:37 PM David Davis wrote: > I am also concerned about the lack of human involvement and the potential > for things to be merged accidentally. I definitely could see that happening. > > I like the idea of having the PR processor only merge if a label (eg > "Merge when

Re: [Pulp-dev] PR merging

2020-09-30 Thread David Davis
I am also concerned about the lack of human involvement and the potential for things to be merged accidentally. I definitely could see that happening. I like the idea of having the PR processor only merge if a label (eg "Merge when Ready") is present. The question then is whether it should be

Re: [Pulp-dev] PR merging

2020-09-30 Thread Matthias Dellweg
This just reminds me that Gitlab has a very nice "merge when CI passes button" to decouple the merge question from the reviews. The only way i could see this happen in Github is via setting a label that instructs the PR processor to merge when (label is set) && (ci is green) && (other conditions).

Re: [Pulp-dev] PR merging

2020-09-29 Thread Daniel Alley
I have some doubts about the cost/benefit ratio of coding automation to merge PRs vs. simply changing the default option / being selective about which options are available. I like the idea in general though. A lot of projects do something like this. I occasionally contributed to the Servo

[Pulp-dev] PR merging

2020-09-29 Thread David Davis
Hi all, Last week the discussion about how to merge PRs got me thinking about how we could potentially programmatically merge PRs. The openshift project on github does this[0] and I wondered if it would work for Pulp. I think the main benefits would be (1) we'd be able to code how to best merge