Automating backports

During our pulpcore meeting, we recognized that the process of committing fixes to release branches (ie backporting) was completely manual and cumbersome. We identified patchback as a possible tool we could use to automate our backport process. I think we could use this tool but we’d have to make some changes to our backporting process.

Patchback

Patchback is a github bot which can automatically open cherry pick PRs with changes to release branches. This would involve definining a config and then labeling PRs with the appropriate label (see https://github.com/ansible/galaxy_ng/pull/858#event-5308638474 as an example). After that, patchback will automatically open a PR with the change against the release branch (see https://github.com/ansible/galaxy_ng/pull/968).

Changing our Backport Process

We would need to modify our backport and release processes in order to use patchback. I think these changes would suffice:

  • Keep cherry pick commits attached to the original issues instead of reattaching them to their respective backport request.
  • Disable the checking of issue statuses in the CI for PRs/commits against release branches.
  • Update the release automation to no longer fail/update any issue if it is already attached to a different milestone.

I believe that these changes should allow us to use patchback. The one shortcoming is that milestones in redmine wouldn’t necessary contain all the issues in the release. But we could use the changelog as the canonical list of changes in a release.

Questions

  • What do we do with backport tracker type in redmine?
    • Get rid of it? How do stakeholders request backports?
  • Who is responsible for setting the labels for PRs?
    • We could potentially automate this.
  • Who handles failed cherry picks?
1 Like

If we remove the backport tracker, how can downstream monitor whether a patch is released in a certain z-stream?
Is patchback able to change fixes #ABCD to re #abcd to make all the linters happy?

If we remove the backport tracker, how can downstream monitor whether a patch is released in a certain z-stream?

That’s a good question and sort of along the lines of my question about how stakeholders request backports if we get rid of the backport tracker.

I know we didn’t have/use the backport tracker in Pulp 2 but I can’t remember how we handled such use cases.

Is patchback able to change fixes #ABCD to re #abcd to make all the linters happy?

I don’t believe so–not in its current form. But maybe this is something we could request.

I’m testing patchback on pulp_ansible,

On my first test, I just added backport-0.11 label on a merged PR, and a few seconds later patchback opened a PR: https://github.com/pulp/pulp_ansible/pull/764#issuecomment-1000258530

But patchback’s PR failed on commit message validation:

So I disable the commit message validation for patchback to see if the rest of the CI job would work,
but patchback failed to cherry-pick: https://github.com/pulp/pulp_ansible/pull/780#issuecomment-1000348636

when cherry-picking a “noissue” PR, patchback works successfully - https://github.com/pulp/pulp_ansible/pull/782

1 Like