[Pulp-dev] Cherry pick process

[David Davis]

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
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20191125/d1950fec/attachment.htm>