[Pulp-dev] Cherry pick process

Fri Nov 22 20:15:07 UTC 2019

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.

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.

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/20191122/e10447ef/attachment.htm>