[Pulp-dev] Cherry pick process
bmbouter at redhat.com
Fri Nov 22 15:34:56 UTC 2019
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.
> 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>
>> 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>
>>> On Thu, Nov 21, 2019 at 9:01 AM David Davis <daviddavis at redhat.com>
>>>> 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 (see this PR
>>>> 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
>>>> - 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?
>>>>  https://pulpproject.org/2019/11/04/pulp-3-GA-update/#cherry-picking
>>>>  https://github.com/theforeman/prprocessor
>>>>  https://github.com/Katello/katello/pull/8441
>>>>  https://pulp.plan.io/issues/4365
>>> Mike DePaulo
>>> He / Him / His
>>> Service Reliability Engineer, Pulp
>>> Red Hat <https://www.redhat.com/>
>>> IM: mikedep333
>>> GPG: 51745404
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
> Pulp-dev mailing list
> Pulp-dev at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev