-
Notifications
You must be signed in to change notification settings - Fork 15
Fetch entire branch #25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Try to get ref
Try without fetching all branches
Wouldn't the bot's commit also trigger those same downstream jobs? So if there was a failure in the original push, it would reoccur in the bot's push? (or it could be resolved, but either way, the status would be "correct") |
| uses: actions/checkout@v4 | ||
|
|
||
| with: | ||
| ref: ${{ github.event.pull_request.head.ref }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can't assume the event that started the job is a pull_request event. It could just as easily be a push event, workflow_dispatch, scheduled cron run, workflow_call, or something else entirely.
|
@packagespace did you intend to publish your fork to the marketplace? Would you consider renaming your fork so that the official action can be published under that name? |
As far as I remember, the bot's commit did not trigger the same jobs. I'm not using this on any project anymore but I've attached a screenshot of what happened.
I've de-listed it, no idea publishing my fork would block anything from anyone else from being published. |

This allows to push auto-fixes to the branch instead of being in detached head state (closes #23)
I have tested my fork on one of my projects and I can confirm that it works.
However, there's a separate issue: the bot's commit and push trigger a new CI pipeline immediately, which can mask failures from later stages of the original user-initiated pipeline.