[Pulp-dev] Cherry pick process

[Ina Panova]

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