Automate backports to LTS branches #9641
Conversation
github-actions
bot
added
the
keep pr updated
|
Visit the preview URL for this PR (updated for commit 23b16c9): https://gloo-edge--pr9641-npolshak-add-backpor-lxcnr6q8.web.app (expires Fri, 05 Jul 2024 20:53:48 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 Sign: 77c2b86e287749579b7ff9cadb81e099042ef677 |
| runs-on: ubuntu-latest | ||
| name: Backport into our v1.15.x LTS branch | ||
| if: | | ||
| contains(github.event.pull_request.labels.*.name, 'Backport: 1.15.x') && |
There was a problem hiding this comment.
We already have the concept of release/1.N which tends to indicate on issues, which versions a given change should go to. Instead of adding new labels per LTS branch, what if we added a auto-backport label, and we use that plus release/1.N to identify which branches to backport this to?
| on: | ||
| pull_request: | ||
| branches: | ||
| - main |
There was a problem hiding this comment.
Is it possible to make this also to be run with a manual trigger? I like the idea of reducing the burden on developers, and I imagine that we'd first start with a tool developers to initiate, and then work to automate. I'm also thinking of the case where a decision to backport a piece of work is identified after it has merged
| ${{ github.event.pull_request.user.login }} | ||
| reviewers: | | ||
| ${{ github.event.pull_request.user.login }} | ||
| cherry_pick_v1_16_x_backport_pr: |
There was a problem hiding this comment.
Is there a way to use the release labels to determine which versions to target? I think it would be cool if we could have a single job that runs, and mainly works by taking a source commit, and a target branch (or a list of them) and opens PRs to each branch. That way each time we add an LTS branch, we don't need to update this job
There was a problem hiding this comment.
Another idea: In https://github.com/solo-io/solo-projects/issues/6395 I propose having LTS branches own the automation they need. Would it be useful/possible to follow that model, where the LTS branch owns the workflow to open a PR against it, and this job on main is just the orchestrator?
| token: ${{ secrets.PERSONAL_ACCESS_TOKEN }} | ||
| fetch-depth: 0 | ||
| - name: Cherry pick into v1.17.x LTS branch | ||
| uses: ashleywang1/[email protected] |
There was a problem hiding this comment.
Is it possible with this action to open a PR in a draft state, or apply custom labels to the PR itself? I imagine that our changelog-bot would fail anyway on the new PR, but I wonder if it's valuable to either open a draft PR or add the work in progress label, to ensure that user intervention is required before the PR is eligible to merge
| description: | | ||
| "Developers should add a label like `Backport: 1.17.x` on their PRs. After your PR merges, the backport.yaml | ||
| Github Action will run, and the PR with the title like '[v1.17.x] {old pr title}' should be created." | ||
| skipCI: true |
There was a problem hiding this comment.
^This is not a valid directive in this repo. https://github.com/solo-io/gloo/tree/main/ci#special-directives-to-skip-ci is the list that we support. Do you think it's worth it to add support for this one?
I kind of llike the granular approach so you can opt-out of certain pieces of CI, though I could see value in a global definition as well. wdyt?
| pull_request: | ||
| branches: | ||
| - main | ||
| types: ["closed"] |
There was a problem hiding this comment.
It looks like there is no "merged" event that we can use. Should we add some logic in the job to skip events where a PR was closed (not merged)?
Alternatively, could/show we use the on push to main trigger, like https://github.com/solo-io/gloo/blob/main/.github/workflows/cache-setup.yaml#L7?
Description
Backports are annoying. This automates opening a backport PR if a developers includes label (ex.
Backport: 1.17.x) on their PRs. After the PR merges, the backport.yaml Github Action will run, and the PR with the title (ex. '[v1.17.x] {old pr title}') should be created.This is based on the backport automation that Gloo Mesh Enterprise uses:
API changes
None
Code changes
None
CI changes
Docs changes
None
Context
None
Interesting decisions
None
Testing steps
None
Notes for reviewers
None
Checklist: