I've filed an issue here: https://pulp.plan.io/issues/5808. Feedback on the issue is welcome.
David On Tue, Nov 26, 2019 at 8:51 AM Brian Bouterse <bmbou...@redhat.com> wrote: > Filing more issues sounds good. Email notifications sound good. Can we > start with the bare minimum so we can get something basic going soon? > > On Tue, Nov 26, 2019 at 7:55 AM David Davis <davidda...@redhat.com> wrote: > >> Yes but it's complicated. Travis does have a setting for email >> notifications[0]. However, I don't think you can configure it specifically >> to notify on failed cron jobs and we'd have to expose this setting via the >> plugin_template. There's also the problem that Travis will notify you for >> forks that are running in Travis[1] although it looks like you can work >> around this by encrypting a notification setting such as an email[2]. >> >> If all of that sounds acceptable, I can open a separate issue. >> >> [0] >> https://docs.travis-ci.com/user/notifications/#configuring-email-notifications >> [1] https://github.com/travis-ci/travis-ci/issues/329 >> [2] https://github.com/travis-ci/travis-ci/issues/5063 >> >> David >> >> >> On Tue, Nov 26, 2019 at 4:07 AM Tatiana Tereshchenko <ttere...@redhat.com> >> wrote: >> >>> +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
