[Pulp-dev] Cherry pick process

Tue Nov 26 12:54:39 UTC 2019

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/20191126/65ef596c/attachment.htm>