+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 <bmbou...@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 <mikedep...@redhat.com> > wrote: > >> >> On Thu, Nov 21, 2019 at 9:01 AM David Davis <davidda...@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@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev