v8 and v9 fail for the second target OS
aiurovet opened this issue · 4 comments
Describe the bug
I'm using this GitHub action at the end of my workflow to push the produced binaries (executable, app package) back to version control. It worked fine for v7, but v8 and v9 fail on the second target OS (windows-latest after ubuntu-latest)
Workflow used
- name: Pushing the new binary to the version control
uses: EndBug/add-and-commit@v9
with:
message: 'Pushing the new binary back to the version control'
add: 'bin/${{runner.os}}/* --force'
Expected behavior
Should push the compiled binary to sub-folder bin of my repo.
Logs
The repo is still private https://github.com/aiurovet/chest/actions/runs/4753526214/jobs/8445219531
Logs
Error: Error: Pushing to https://github.com/aiurovet/chest
error: failed to push some refs to 'https://github.com/aiurovet/chest'
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.
Since v8, the action doesn't run git pull
by default. You can change to the previous behavior by using setting pull: --rebase
in your inputs
Thank you, @EndBug. I did as you advised, but got an error on the first target (ubuntu-latest):
Error: Error: error: cannot pull with rebase: Your index contains uncommitted changes.
I guess, this is because the produced binaries are part of the version control. The rest was committed and pushed to trigger the CI (build). But again, everything worked in v7.
Should I use add: 'app/${{runner.os}}/* --force --rebase'
instead of pull: --rebase
?
Well, you can't use --rebase
on git add
, so that's a no for sure...
I think this relates to issue #492: it's a bit tricky to find a solution that works for every scenario, and the current is for sure not the best one...
It's a bit of a workaround, but why don't you try manually pulling before the action?
- run: git pull
- uses: EndBug/add-and-commit@v9
with:
add: # ...
To be honest, concurrency it's something this project was never great to handle: it's for sure something to improve in the future
Yes, that worked!
Thank you very much for the quick response and advice.