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
