Open kenorb opened 4 years ago
As for the workaround, I've re-pulled and pushed again after the job failure.
- name: Commit files
run: |
git config --local core.autocrlf false
git config --local user.email "${{ github.actor }}@users.noreply.github.com"
git config --local user.name "${{ github.actor }}"
git add . && git add --renormalize .
git pull origin ${{ github.ref }} --autostash --rebase -X ours
git commit --allow-empty -am "${{ github.workflow }}"
NO_PAGER=1 git --no-pager diff HEAD^
- name: Push changes
uses: ad-m/github-push-action@master
with:
branch: ${{ github.ref }}
github_token: ${{ secrets.GITHUB_TOKEN }}
- name: Re-pull on failure
if: ${{ failure() }}
run: git pull origin ${{ github.ref }} --autostash --rebase -X ours
- name: Re-push on failure
if: ${{ failure() }}
uses: ad-m/github-push-action@master
with:
branch: ${{ github.ref }}
force: true
github_token: ${{ secrets.GITHUB_TOKEN }}
But would be great to add some pull feature and re-try system to this action to try again, in case the remote HEAD changed.
Hey @kenorb this really helped, thank you!
i have the same issue, is there any planned fix for this ?
@gergokee I think, the issue is already solved by using the --atomic
option by default.
@ZPascal i read about atomic but that is not going to solve this issue. Atomic push is a possiblity to push to different branches as the same time, however this does not directly solve the issue of concurrent asynchronous pushes to the same reference (e.g., the same branch) where one push occurs slightly after the other. The atomic push ensures that either all or none of the specified references are updated in a single operation, maintaining consistency across multiple branches or tags being pushed simultaneously. However, it does not manage or resolve conflicts arising from concurrent pushes to the same reference. (We've solved it with some "ugly" workarounds upon catching push error...)
The following error can happen at random especially for jobs in parallel (matrix). This could be related to race condition.
My config:
I don't want to force push (because obviously something changed upstream right after the pull), so maybe integrating pull feature as well right before push could be useful and do some customizable number of retries?
One workaround is to move push action outside of matrix jobs by uploading changed from from matrix job, then downloading artifacts (e.g. patches) and push the changes at the final stage.