Force Pushing to Write Back Branch

[danielnazareth89]

Hello,

I have configured and argocd application called test-app that tracks a branch called argocd (main is protected). I then setup argocd-image-updater to checkout from main and then push to argocd branch, but I get the below error. How can I force push to the write back branch?

level=error msg="Could not update application spec: could not push argocd to origin: `git push origin argocd` failed exit status 1: Warning: Permanently added 'github.com' (ED25519) to the list of known hosts.\r\nTo github.com:test-repo.git\n ! [rejected]        argocd -> argocd (non-fast-forward)\nerror: failed to push some refs to 'github.com:test-repo.git'\nhint: Updates were rejected because the tip of your current branch is behind\nhint: its remote counterpart. Integrate the remote changes (e.g.\nhint: 'git pull ...') before pushing again.\nhint: See the 'Note about fast-forwards' in 'git push --help' for details." application=test-app

My git annotations are

argocd-image-updater.argoproj.io/git-branch: main:argocd
argocd-image-updater.argoproj.io/write-back-method: git:secret:argocd/test-repo

Appreciate any insight on the recommended approach here!

[LS80]

I have a similar issue. I wonder whether the main branch is checked out every time a commit is made to the branch? So when any subsequent commits to the target branch are made (e.g. multiple applications using the same branch) the push fails because it's behind the remote branch. A force push would lose the previous commits so that wouldn't work for my case.

Perhaps the behaviour should be that it only checks out the base branch if it is ahead of the target branch, otherwise the target branch is checked out. That way any existing commits to the branch from previous updates or other applications will be retained and the push would succeed.

[sambonbonne]

I have a similar issue.

The force push solution would work but would erase previous commit and force having one commit for all updates in once. It's not a problem for me but it wouldn't suit any use case.

I think the main use case of the base branch is to ensure the target branch is up to date with latest changes but prevent commit directly in the target revision.

Maybe a good flow would be:

• pull the base branch
• if the target branch already exist, pull it and merge the base branch into it
• if the target branch doesn't exist, create it from the base branch
• commit what needs to be in the target branch and push the target branch

It's just my idea of a flow working with my use case without breaking too much the current workflow but I don't know if it would suit all users needs.

[jtanaya]

Any updates on this?

[yevon]

Same here, I just got this issue. Is there any recommendations on how to avoid this and how to prevent this from happening? Or a way to force it.