Automatically backport a closed PR to specific branches about backport-action HOT 8 CLOSED

No worries, I understand you have your own priorities. If I do end up having time I'll see if I can submit a PR.

from backport-action.

Awesome, I'll see if I can implement this again 😀

from backport-action.

Hi @Aeolun 👋 Thanks for reporting.

Can you clarify your use case a bit? Do you want to backport all pull requests, or only a select few? If you still need to select them, how would you mark pull requests as needing to be backported? If it's with a label, then why not just use the label with specified target branch?

In addition, what happens when you switch to a new backport target branch? Are you sure you no longer want to backport to the previous target? I'm asking this because you'd lose the flexibility to target different branches.

At Zeebe, we support versions for about 12 months. The effort to create a new label and delete the old ones is negligible. Labels can also only be created and deleted by maintainers, so they determine what is available. And it's easy for contributors, because they label a PR and GitHub's autocomplete on labels helps them pick the right one(s).

I'd be curious to hear your thoughts about this, but at this time I'm hesitant to support it.

from backport-action.

@korthout We basically have a several release branches in parallel.

So say we'll have a 'master', 1.1 and 1.2 branch. Any change made should be carried forward to new versions.

Everything in 1.1 needs to be merged/cherry picked to 1.2 and master, and everything for 1.2 needs to be merged/cherry picked to master.

We can do this by manually tagging every PR to 1.1 with backport 1.2 and backport master, but that never changes (as long as 1.1 exists), so doing it on every PR when it is already decided by the PR target feels redundant.

from backport-action.

@Aeolun Thanks for clarifying. Do I understand correctly that you want to use a workflow input to define the target branch(es), and then conditionally run the backport action only if the target was a specific branch?

In your example, there's a clear difference between what needs to happen when something is merged to 1.1, compared to merged to 1.2. Would you specify multiple jobs that are conditionally run on every PR? Or how do you see this, when used in a workflow?

from backport-action.

Yeah, basically. As I see it we'd just have one workflow on each branch that specified in the input what branches to create a backport for.

Since the workflow files are already unique per branch, if someone make a PR for a feature branch based off 1.0, it'd already have "merge to 1.1 and master" input on that job, where for 1.1 we'd change that default to only "merge to master", so any feature branch based of of 1.1, would only backport to master.

I guess what is different about our workflow is that we're not really backporting, we're forward-porting ;) changes are made on the release branch and them sent to master/newer release branches, instead of the other way around.

from backport-action.

@Aeolun I can see it now 💯 Thanks for the additional explanation. I personally never considered different workflow files on different branches, but it makes total sense when you're forward-porting. You've convinced me. So thanks for opening my eyes.

I'm currently finishing up

• #289

I'd like to keep focus on that release and avoid adding too many other changes to it.

I'd welcome PRs for this shortly after v1-rc1 is out. Otherwise, I can pick this up somewhere after v1 is fully released.

from backport-action.

Hi @Aeolun. I finally had some time to complete #340 and release it. The target_branches input is now available on v1, v1.3, and v1.3.0 🎉

from backport-action.