Handle failed push error when head falls behind

[palewire]

This error can crop up if another action has committed since your current action started. Would it be okay to figure out a way for this action to pull in this circumstance?

To https://github.com/palewire/news-homepages
 ! [rejected]        main -> main (non-fast-forward)
error: failed to push some refs to 'https://github.com/palewire/news-homepages'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
Error: Invalid status code: 1
    at ChildProcess.<anonymous> (/home/runner/work/_actions/stefanzweifel/git-auto-commit-action/v4/index.js:17:19)
    at ChildProcess.emit (events.js:314:20)
    at maybeClose (internal/child_process.js:1022:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:287:5) {

That comes from this job

[stefanzweifel]

Hi. Yeah, this is a known edge case of the Action:

The following is a list of edge cases the Action knowingly does not support: No git pull when the repository is out of the date with remote. The Action will not do a git pull before doing the git push. You are responsible for keeping the repository up to date in your Workflow runs.

I don't have any plans on adding options to "fix" this. User will have different preferences to either use git rebase or git merge. There will be merge conflicts that need to be handled. The list goes on. :)

I suggest adding a new step to your workflows to always run git pull before attempting to create the commit

- name: Pull Remote Changes
  run: git pull

[OmarJaroudi]

It doesn't feel like something the consumer should worry about, at least when the issue arises simply because the workflow that uses this action checks out another branch. So for example, if my workflow looks like

- uses: action/checkout@v3
  with:
     ref: a-branch
- uses: stefanzweifel/git-auto-commit-action@v4
  with:
     branch: some-other-branch
   etc

the action fails if some-other-branch exists and commits have been made to it, but the fact that I'm running this workflow means that by default I just want to push on top of the latest HEAD of the branch at the time. The reason I think this is not an actual issue related to merge strategies is that this is all abstracted if I checkout the same branch I am pushing to from the start. So the following workflow doesn't run into issues

- uses: action/checkout@v3
  with:
     ref: my-branch
- uses: stefanzweifel/git-auto-commit-action@v4
  with:
     branch: my-branch
   etc

regardless of what commits have been made to my-branch because the branch was checked out at the beginning. But we can't always check out the branch we are going to push to because the branch might not exist yet, which I think we realize because the action has a create_branch field. That being said, I think the ask here is to just add support to fetch the branch passed to the action from the remote repo to local before trying to commit, same as what would have happened if we manually call checkout, noting that we shouldn't need merge strategies in this case because the local branch is created from scratch when things are running in github actions. Does that make sense?

So essentially, if I do the following I can get around issue

 - name: Checkout sync branch if it exists
        run: |
          (git ls-remote --heads --exit-code origin my-branch &>/dev/null) && (git checkout --progress --force -B my-branch refs/remotes/origin/my-branch)
- uses: stefanzweifel/git-auto-commit-action@v4
  with:
     branch: my-branch
   etc     

but I think having it as a separate step in the workflow is much uglier than having it as part of the action out-of-the-box

[stefanzweifel]

@OmarJaroudi Thanks for this detailed feedback on this issue!

The create_branch-option always bugged me a bit. Can't even remember why that one was added.

Probably the main reason this issue hasn't been truly resolved yet, is that I never come across it. 🤷😄 In all the workflows I maintain and use, I never run into that issue that remote is out of date with local. So it never really becomes a pain-point for me.

I plan to work on the next major version of this Action (v5) over the new few months. Will try to figure out a good way to support this. Other projects looked for more fun to me the last few months than building an abstraction around certain git-command.

But I also understand, that the lack of a proper git-pull-implementation in this Action limits certain usages.

[OmarJaroudi]

@stefanzweifel thank you for this awesome effort all the same!