Backports?

[ihnorton]

Hi, are there any plans to support automated backporting? For context: in many project workflows, some PRs against the active-development branch may also need to be cherry-picked on to release branch(es), most often for bug-fixes. For example we currently use https://github.com/tibdex/backport which does cherry-picks after a PR is merged based on PR labels such as backport-release-X.y. However, the action has some limitations -- so I am looking around for alternatives and noticed that kodiak might already have most of the tooling necessary to do backports.

[chdsbd]

Hey @ihnorton, thanks for the question!

This isn't something I've considered, because I haven't had to do this before in a project, but I'm open to supporting this in Kodiak.

Do you have an idea about what Kodiak would need to do to support this? I'm curious what the configuration would look like and what the developer flow would be to use this feature.

[ihnorton]

Hi @chdsbd,
Our workflow is set up such that almost all PRs target the dev development branch. Periodically, we create a new release branch forked from dev, for the next release version. This branch will be used to create the final release artifacts, after a "release candidate" testing period. Once the release is out, we may need to do follow-up releases to fix bugs without forcing an update to the most recent release. Usually these bug fixes are applied to dev first, and then "backported". The way backporting currently works is:

• PR is labeled as backport release-X.Y using GitHub issue labels
  • Backports are done by a github action which gets a notification for each PR-closed or PR-labeled event: https://github.com/TileDB-Inc/TileDB/blob/dev/.github/workflows/backport.yml
• After the PR is merged to dev, the backport action attempts to apply the HEAD commit against any branches identified with the backport-release-X.Y label.
  • If the commit applies cleanly, then the action script opens a PR against the release-X.Y branch
    • We run CI and (currently) manually merge to the release branch
  • If not, the bot comments on the original PR with some suggestions for how to manually backport

In case it helps, here are some PRs exemplifying the process above:

• Original PR: [Backport release-2.8] Add support for group members to have names TileDB-Inc/TileDB#3072
  • resulting backport PR: [Backport release-2.8] Add support for group members to have names TileDB-Inc/TileDB#3072
• Failed backport message on a different PR: Add support for group members to have names TileDB-Inc/TileDB#3068 (comment)

Clearly, kodiak could help to automate the "merge backport PRs manually" step. But I'm also wondering if it would be in-scope to actually create the backport PRs? One issue we have with the current github action we use is that it only applies the HEAD commit. Whereas I believe kodiak already has some capabilities to apply a range of commits to a target branch (and then in principle, for clean backports, it could even just push those directly to the release-X.Y branch once CI passes).

[chdsbd]

Kodiak probably has the same limitations as the GitHub action because Kodiak uses the GitHub API for all git operations.

I think this would be kind of complicated to implement, so it would probably be easier to implement using a fresh codebase

[ihnorton]

Understood, in any case, thanks for the consideration!