[Pulp-dev] Cherry pick process

Fri Dec 20 21:04:43 UTC 2019

The cherry pick stage is now live. There's information in the
plugin_template README[0] on how to set it up but here's also a quick start
guide:

0. Make sure your travis config files are up to date
1. Set cherry_pick_automation and stable_branch in template_config.yml
2. Set environment variables GITHUB_USER and GITHUB_TOKEN in Travis. Tokens
can be generated at https://github.com/settings/tokens
3. Create a cron job if you don't already have one
4. Create a PR label "Needs Cherry Pick"

After that, for whatever merged PR(s) have the label "Needs Cherry Pick",
the cherry pick stage of the cron job will open a PR with all the commits
against the stable_branch. Here's an example PR from pulpcore:

https://github.com/pulp/pulpcore/pull/465

If you have any questions, don't hesitate to ask me via email or IRC.

[0] https://github.com/pulp/plugin_template

David

On Tue, Nov 26, 2019 at 9:16 AM David Davis <daviddavis at redhat.com> wrote:

> 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/20191220/ae28e1a4/attachment.htm>