[Pulp-dev] Cherry pick process

Tue Nov 26 13:51:18 UTC 2019

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 <daviddavis at 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 <ttereshc at 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 <daviddavis at 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 <bmbouter at redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Nov 22, 2019 at 3:15 PM David Davis <daviddavis at 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 <bmbouter at 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 <ipanova at 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 <bmbouter at 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 <
>>>>>>>> mikedep333 at redhat.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Nov 21, 2019 at 9:01 AM David Davis <daviddavis at 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 at redhat.com
>>>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Pulp-dev mailing list
>>>>>>>> Pulp-dev at redhat.com
>>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Pulp-dev mailing list
>>>>>>> Pulp-dev at redhat.com
>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Pulp-dev mailing list
>>>>>> Pulp-dev at redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>>
>>>>> _______________________________________________
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20191126/f96c1966/attachment.htm>