The cherry pick stage is now live. There's information in the plugin_template README[0] on how to set it up but here's also a quick start guide:
0. Make sure your travis config files are up to date 1. Set cherry_pick_automation and stable_branch in template_config.yml 2. Set environment variables GITHUB_USER and GITHUB_TOKEN in Travis. Tokens can be generated at https://github.com/settings/tokens 3. Create a cron job if you don't already have one 4. Create a PR label "Needs Cherry Pick" After that, for whatever merged PR(s) have the label "Needs Cherry Pick", the cherry pick stage of the cron job will open a PR with all the commits against the stable_branch. Here's an example PR from pulpcore: https://github.com/pulp/pulpcore/pull/465 If you have any questions, don't hesitate to ask me via email or IRC. [0] https://github.com/pulp/plugin_template David On Tue, Nov 26, 2019 at 9:16 AM David Davis <davidda...@redhat.com> wrote: > 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
