Feature request: configurable branch force pushing

[jracollins]

Use case:

A workflow I am using currently is to push the image automation updates to a different branch than the one flux is watching. A Github action then opens a PR on any commit to that branch (and the branch is subsequently pruned upon merging).

This allows users to approve/deploy releases manually, whilst keeping most of the workflow (i.e: committing and pushing tags) automated.

Current Issue:

If a branch with image updates is created by flux, and a new commit comes into the main branch that it was branched off, any subsequent updates are blocked because the Git history on the opened branch is out of sync. The "solution" is to rebase the branch and add the image update commit. However this requires a force push to the new branch, which flux currently does not do.

This will occur when using separate branches for multiple applications image automation updates.

Eg:

/main
/app-a-update 
/app-b-update

If using flux to commit on the same branch as it is watching (ie, auto deploy on new image tag) this is a non issue, as there is no rebasing required.

However if in this example, /app-a-update branch is merged, the commit on /app-b-update needs to be rebased (and then forced pushed), currently this is not possible and fails. The current workaround I am using is to manually delete the branch and wait for flux to recreate.

Proposal:

apiVersion: image.toolkit.fluxcd.io/v1alpha2
kind: ImageUpdateAutomation
metadata:
  name: my-application
  namespace: flux-system
spec:
  interval: 1m0s
  sourceRef:
    kind: GitRepository
    name: my-application
  update:
    path: ./production
    strategy: Setters
  git:
    checkout:
      ref:
        branch: main
    push:
      branch: my-application-production-update
      force: true # this would be the proposed setting/flag
    commit:
      author:
        email: fluxcdbot@users.noreply.github.com
        name: fluxcdbot

This should default to false and remain backward compatible.

Branch protection in GitHub etc can also prevent any unintended rewriting of important branches.

Initial Discussion in Flux Slack: https://cloud-native.slack.com/archives/CLAJ40HV3/p1627660144049300

[squaremo]

any subsequent updates are blocked because the Git history on the opened branch is out of sync.

I can see why you want branches to be rebased, but I don't understand this statement -- are commits to the PR blocked by GitHub when it is not fast-forwardable? Or is the PR just not mergeable, until it's been rebased.

The "solution" is to rebase the branch and add the image update commit. However this requires a force push to the new branch, which flux currently does not do.

The controller should not need to force push, because it always gets a fresh clone. Occasionally you might see a failed push, if the branch head changed in the small period between cloning and pushing, but the update would be immediately retried, and likely (or at least eventually) succeed. If the push branch gets rebased, it'll just commit on top of that. Have you seen something different?

[jracollins]

The issue I was running into seems to have been resolved after updating to more recent version of flux - I just updated to latest try see if I could grab some logs showing the issue, and a load of commits came through.

Based on this, I think my understanding of how flux is actually working is wrong. I was under the impression from the wording and docs that flux is pulling just the checkout branch, effectively running git checkout -b pushbranch and then applying changes from image policy, committing and pushing? Which was what the symptoms of my looked like, and why I thought the need for force pushing.

It seems more clear now that it is pulling the latest push branch from origin, finding the latest tag from the Imagepolicy, applying, and if there is a diff, commit and push? - this would mean the "checkout" branch is only used for when the branch doesn't already exist?

[squaremo]

It seems more clear now that it is pulling the latest push branch from origin, finding the latest tag from the Imagepolicy, applying, and if there is a diff, commit and push? - this would mean the "checkout" branch is only used for when the branch doesn't already exist?

That's the one, yes. I'm sorry the docs led you to believe it worked otherwise -- something for me to look into.

Does this end up working in a way that suits you?