[Pulp-dev] Cherry pick process

David Davis daviddavis at redhat.com
Tue Nov 26 14:16:24 UTC 2019


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 <bmbouter at 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 <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/83a8b2cf/attachment.htm>


More information about the Pulp-dev mailing list