Automatic Backport PR Tags

solo-io / gloo

The Feature-rich, Kubernetes-native, Next-Generation API Gateway Built on Envoy

https://docs.solo.io/

Apache License 2.0

4.08k stars 437 forks source link

Automatic Backport PR Tags #6734

Open nfuden opened 2 years ago

nfuden commented 2 years ago

Version

No response

Is your feature request related to a problem? Please describe.

Backports are painful and take alot of time especially with multiple repos.

Describe the solution you'd like

In general it would be nice to have as much of the backport process automated. For this first chunk of effort we propose starting with a PR tag that will auto cherry pick and open Backport PRs based on some tag. This is similar to what is in place for isitio.

Describe alternatives you've considered

No response

Additional Context

No response

github-actions[bot] commented 4 months ago

This issue has been marked as stale because of no activity in the last 180 days. It will be closed in the next 180 days unless it is tagged "no stalebot" or other activity occurs.

sam-heilbron commented 1 month ago

We have had some previous attempts at introducing this:

[Nathan] https://github.com/solo-io/solo-projects/pull/5576
[Nina] https://github.com/solo-io/gloo/pull/9641

I think for the most part we agree that some form of automation would really help. We could explore this in phases:

Local tool that devs can run from their machine
Manual workflow that devs can run in CI
Some form of automation to run the workflow after a PR merges based on some criteria

I'm not sure what we want to bite off first. One consideration is just that having some toil to our backport process can at times be a good thing. While backports are good to perform when we are introducing fixes, they also include a certain amount of risk that should be evaluated each time.

cc @timflannagan for recent slack question about the state of this work

timflannagan commented 1 month ago

While backports are good to perform when we are introducing fixes, they also include a certain amount of risk that should be evaluated each time.

@sam-heilbron Good point, but I think this is better tackled with a documented process that covers the following:

Document our backport policy. How far back do we backport CVEs/bug fixes? What about low or medium severity bugs? etc.
Uses labels to indicate how far back GH issues need to be backported. Ex: Needs Backport 1.17.x. This can be added during refinement so there's less ambiguity / more signal to developers once engineering picks up an issue

I sketched that out inline, so that list doesn't have to be definitive. Having this in place helps solve "we don't want everything to be backported due to N reasons (e.g. risk, regressions patch versions, etc.) so we intentionally introduce friction in the process to help mitigate that". WYDT?