Creates new branch even if it exits

[1itachi]

Version of the Action
v4.9.0

Describe the bug
Creates a new branch even if the remote with the same name exists.

Switched to a new branch 'automatic-sync'
INPUT_FILE_PATTERN: .editorconfig
To https://github.com/<repo>
 ! [rejected]        HEAD -> automatic-sync (non-fast-forward)
error: failed to push some refs to 'https://github.com/<repo>'
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.

To Reproduce
Steps to reproduce the behavior:

1. Give a new branch name and commit some changes
2. Run the same workflow a second time

Expected behavior
Needs to check if the remote branch exists, compare the difference, and commit only if a change is found.

Used Workflow

name: sync template
on: push

jobs:
  check-version-change:
    runs-on: [self-hosted, linux]
    steps:
    - uses: actions/checkout@v2

    - name: Copy file
      run: ***does something*******

    - name: commit and push
      uses: stefanzweifel/git-auto-commit-action@v4
      with: 
        commit: "Apply automatic changes"
        branch: "automatic-sync"
        file_pattern: ".editorconfig"

[stefanzweifel]

Thanks for reporting @itachi1994

Quick question: Did this behaviour work for you previous to v4.9.0? (v4.9.0 has been released just 3 days ago)

If I understand the issue correctly, you're currently:

• checking out the repo in it's default branch (eg main or master)
• copy files
• push them to a automatic-sync branch on remote

Maybe adding push_options: '--force' would solve this problem for you?
I would like to avoid adding default behaviour how the Action deals with such conflicts.

---

If this is a more general bug that appeared in v4.9.0 I'm giving my best to fix this as soon as possible.

[1itachi]

@stefanzweifel Thank you for getting back to me.
I have the same problem with the older version v4.8.0
--force seems to work, even though it creates a commit.

[stefanzweifel]

@itachi1994 You might also be able to add a git-rebase step in your workflow like this:

     - name: Copy file
       run: ***does something*******
 
+    - run: git rebase origin/automatic-sync
 
     - name: commit and push
       uses: stefanzweifel/git-auto-commit-action@v4
       with: 
         commit: "Apply automatic changes"
         branch: "automatic-sync"
         file_pattern: ".editorconfig"

In #143 I've added a failing test to prove that this is real bug.
It could be solved with a git-rebase step, however, I really don't want to add this step in the Action itself. Users probably want to be in control, how upstream changes are merged or rebased. 🤔

As this seems to be a rare edge case, I would like to just add a note in the README, that users are responsible to solve such issues in their workflows directly.

I will keep this issue open though for a few days. To think about this more and give others the chance to report similar problems.

[spr-saleem]

Thanks for opening this issue, @itachi1994
@stefanzweifel : My team and I are also facing this issue.
It did not exist for us prior to v4.9.0
Our current workaround has been to update our build scripts to pin this dependency to v4.8.0. This has solved this problem.
(See @betamike 's message below for details.)

[betamike]

Output @spr-saleem and I are seeing:

4.8.0 output:

Run stefanzweifel/git-auto-commit-action@v4.8.0
  with:
    commit_message: Apply go/content formatting
    branch: experiment-2
    file_pattern: .
    repository: .
    commit_user_name: GitHub Actions
    commit_user_email: actions@github.com
    commit_author: betamike <betamike@users.noreply.github.com>
    skip_dirty_check: false
    skip_fetch: false
  env:
    GOROOT: /opt/hostedtoolcache/go/1.16.0/x64
Started: bash /home/runner/work/_actions/stefanzweifel/git-auto-commit-action/v4.8.0/entrypoint.sh
INPUT_REPOSITORY value: .
INPUT_BRANCH value: experiment-2
From https://github.com/lytic-health/lytic
 <...>
 * [new branch]        experiment-2            -> origin/experiment-2
<...>
Previous HEAD position was e2cca8ef Merge ee0016ea6168db5f360ab9781ae09f617bcd62a4 into 4508060b6e058e2f1897d27c86d09b596317e2e5
Switched to a new branch 'experiment-2'
M	main.go
Branch 'experiment-2' set up to track remote branch 'experiment-2' from 'origin'.
INPUT_FILE_PATTERN: .
INPUT_COMMIT_OPTIONS: 
INPUT_COMMIT_USER_NAME: GitHub Actions
INPUT_COMMIT_USER_EMAIL: actions@github.com
INPUT_COMMIT_MESSAGE: Apply go/content formatting
INPUT_COMMIT_AUTHOR: betamike <betamike@users.noreply.github.com>
[experiment-2 d330cafb] Apply go/content formatting
 Author: betamike <betamike@users.noreply.github.com>
 1 file changed, 1 insertion(+), 2 deletions(-)
INPUT_TAGGING_MESSAGE: 
No tagging message supplied. No tag will be added.
INPUT_PUSH_OPTIONS: 
To https://github.com/lytic-health/lytic
   ee0016ea..d330cafb  HEAD -> experiment-2
Branch 'experiment-2' set up to track remote branch 'experiment-2' from 'origin'.

4.9.0 output:

Run stefanzweifel/git-auto-commit-action@v4
  with:
    commit_message: Apply go/content formatting
    branch: test-branch
    file_pattern: .
    repository: .
    commit_user_name: GitHub Actions
    commit_user_email: actions@github.com
    commit_author: betamike <betamike@users.noreply.github.com>
    skip_dirty_check: false
    skip_fetch: false
  env:
    GOROOT: /opt/hostedtoolcache/go/1.16.0/x64
Started: bash /home/runner/work/_actions/stefanzweifel/git-auto-commit-action/v4/entrypoint.sh
INPUT_REPOSITORY value: .
INPUT_BRANCH value: test-branch
From https://github.com/lytic-health/lytic
<....>
 * [new branch]        test-branch             -> origin/test-branch
<...>
Switched to a new branch 'test-branch'
INPUT_FILE_PATTERN: .
INPUT_COMMIT_OPTIONS: 
INPUT_COMMIT_USER_NAME: GitHub Actions
INPUT_COMMIT_USER_EMAIL: actions@github.com
INPUT_COMMIT_MESSAGE: Apply go/content formatting
INPUT_COMMIT_AUTHOR: betamike <betamike@users.noreply.github.com>
[test-branch ed17564f] Apply go/content formatting
 Author: betamike <betamike@users.noreply.github.com>
 1 file changed, 1 insertion(+), 1 deletion(-)
INPUT_TAGGING_MESSAGE: 
No tagging message supplied. No tag will be added.
INPUT_PUSH_OPTIONS: 
To https://github.com/lytic-health/lytic
 ! [rejected]          HEAD -> test-branch (non-fast-forward)
error: failed to push some refs to 'https://github.com/lytic-health/lytic'
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:210:5)
    at maybeClose (internal/child_process.js:1021:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:283:5) {
  code: 1
}
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:210:5)
    at maybeClose (internal/child_process.js:1021:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:283:5)

[stefanzweifel]

@betamike @spr-saleem Thanks for reporting. It seems #140 really break some stuff. :/

I've reverted the changes (#144) and released v4.9.1. This will at least not break the Action for others anymore.

Will tackle the problem the original PR tried to solve therefore in another way.

[spr-saleem]

Thanks for the quick turnaround on this, @stefanzweifel. Much appreciated!

Suggestion for the future: consider giving new point releases some time to stabilize before updating the main release tag reference.

E.g. in this case, our dependency was originally simply on v4, which used to reference v4.8.0 until early February 2021. When v4 was updated to reference v4.9.0, our build broke. If v4 had continued to reference v4.8.0 for a while, users like us wouldn't have broken builds.

Users who want the most recent build can always set their dependency to the latest tag which you also provide (and which I appreciate).

This style would be consistent with https://semver.org, as I understand it.

Thanks, again, for authoring and sharing this API.

[stefanzweifel]

I'm closing this issue now. The changes have been reverted a year ago in #144 and released in v4.9.1.

The original feature, pushing commits to a new branch, has been reimplemented and hidden behind a flag in #203. No release has been tagged yet. I will wait 1-2 weeks before tagging v4.14.0 and therefore also upgrading v4.