On Fri, Nov 22, 2019 at 3:15 PM David Davis <davidda...@redhat.com> wrote:
> I think there are a couple caveats with this approach. One thing is I > think Travis will need to do is remove the "Needs Cherry Pick" label since > it's stateless and it won't be able to keep track of what's already been > cherry picked. > > +1, then it's stateless Also, there's the question of what to do when the cherry pick fails. Travis > could fail the job (this would probably be the easiest thing). I imagine > the release engineer will need to monitor the job and manually merge any > failed cherry picks if the job fails. > +1 to Travis failing the job, leaving the labels unchanged, and having a human look at it > > David > > > On Fri, Nov 22, 2019 at 10:35 AM Brian Bouterse <bmbou...@redhat.com> > wrote: > >> I was thinking we could make this happen quicker if we simplify it a bit, >> then we can add on more later. What if we: >> >> 1) Have humans apply the "Cherry Pick" label and not integrate with >> Redmine >> 2) Have Travis run once a day to create the PR of all merged PRs with the >> cherry pick label that have not yet been cherry picked. >> 3) Have a human merge the "cherry pick" PR daily >> >> We could make ^ run as a cron job on Travis, and then this would be >> available to all plugins who configure it to be enabled. >> >> >> On Fri, Nov 22, 2019 at 8:46 AM Ina Panova <ipan...@redhat.com> wrote: >> >>> +1 to automate cherry-picking. I like that depending on the label set, >>> commit will be cherry-picked or not. >>> >>> >>> -------- >>> 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 Thu, Nov 21, 2019 at 10:43 PM Brian Bouterse <bmbou...@redhat.com> >>> wrote: >>> >>>> After cherry picking a whole bunch today, I am very in favor of >>>> automation to do it. >>>> >>>> I had hoped we could avoid writing/maintaining a service, but I looked >>>> around, and I don't see a hosted "cherry-pick bot" like dependabot for >>>> example. Can we set it up to run next to pulpbot? Or maybe we run it as a >>>> cron job on Travis (see below). Overall though big +1. >>>> >>>> >>>> On Thu, Nov 21, 2019 at 12:07 PM Mike DePaulo <mikedep...@redhat.com> >>>> wrote: >>>> >>>>> >>>>> On Thu, Nov 21, 2019 at 9:01 AM David Davis <davidda...@redhat.com> >>>>> wrote: >>>>> >>>>>> On our scrum with Katello yesterday, they raised an issue that since >>>>>> they are developing against our release branches, they need bug fixes to >>>>>> be >>>>>> cherry picked to release branches asap. Currently this is up to release >>>>>> leads, but we've seen this week that this is problematic as two of our >>>>>> release leads have been out/unavailable. >>>>>> >>>>>> One suggestion is to automate the cherry picking process. I think we >>>>>> could develop a PR bot similar to the one Foretello uses[1] (see this >>>>>> PR[2] >>>>>> as an example). I think the basic workflow for this bot would be: >>>>>> >>>>>> - If a PR is created with no issue attached or [noissue], it would >>>>>> loudly warn that no issue is attached >>>>>> - If the PR has a redmine issue attached, it would: >>>>>> - Attach the PR to the redmine issue and set the status to POST[3] >>>>>> - Set the PR labels depending on the issue type. One of the labels >>>>>> would be 'Needs Cherrypick' if the issue type is a bug. This label can be >>>>>> removed before merge for things we don't want cherry picked. >>>>>> - When any PR is merged with 'Needs Cherrypick', it could either >>>>>> automatically open a cherrypick PR or actually do the cherrypick (falling >>>>>> back to a PR if the merge fails due to conflicts). >>>>>> >>>>> I think it's good to put the cherry-pick back through the PR process >>>> so having it open a PR would be good so that the tests run. Maybe it should >>>> run daily though so we don't increase the travis load and we can test a >>>> group of cherry picks together? Note travis could maybe run this as a cron >>>> job and run it there instead? >>>> >>>> >>>>>> Thoughts? >>>>>> >>>>>> [0] >>>>>> https://pulpproject.org/2019/11/04/pulp-3-GA-update/#cherry-picking >>>>>> [1] https://github.com/theforeman/prprocessor >>>>>> [2] https://github.com/Katello/katello/pull/8441 >>>>>> [3] https://pulp.plan.io/issues/4365 >>>>>> >>>>>> David >>>>>> _______________________________________________ >>>>>> >>>>> >>>>> +1 >>>>> >>>>> -- >>>>> >>>>> Mike DePaulo >>>>> >>>>> He / Him / His >>>>> >>>>> Service Reliability Engineer, Pulp >>>>> >>>>> Red Hat <https://www.redhat.com/> >>>>> >>>>> IM: mikedep333 >>>>> >>>>> GPG: 51745404 >>>>> <https://www.redhat.com/> >>>>> _______________________________________________ >>>>> Pulp-dev mailing list >>>>> Pulp-dev@redhat.com >>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>> >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> Pulp-dev@redhat.com >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>> _______________________________________________ >>> Pulp-dev mailing list >>> Pulp-dev@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev