+1 to the automation of the process Can we configure Travis to send an e-mail if the job fails and not rely on human checking it every time?
Tanya On Mon, Nov 25, 2019 at 6:14 PM David Davis <davidda...@redhat.com> wrote: > I opened an issue to outline the design we're discussing: > > https://pulp.plan.io/issues/5795 > > David > > > On Mon, Nov 25, 2019 at 11:33 AM Brian Bouterse <bmbou...@redhat.com> > wrote: > >> >> >> 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 >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev