stefanzweifel / git-auto-commit-action

Automatically commit and push changed files back to GitHub with this GitHub Action for the 80% use case.
MIT License
1.98k stars 227 forks source link

Occasional 403 Forbidden / 128 Internal Error Code #164

Closed gerryfletch closed 3 years ago

gerryfletch commented 3 years ago

Version of the Action v4.11.0

Describe the bug Occasionally the action will fail with an internal status code of 128, reporting 403 Forbidden:

remote: Permission to {org}/{repo}.git denied to github-actions[bot].
fatal: unable to access 'https://github.com/{org}/{repo}/': The requested URL returned error: 403
Error: Invalid status code: 128
    at ChildProcess.<anonymous> (/Users/runner/work/_actions/stefanzweifel/git-auto-commit-action/v4.11.0/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: 128
}
Error: Invalid status code: 128
    at ChildProcess.<anonymous> (/Users/runner/work/_actions/stefanzweifel/git-auto-commit-action/v4.11.0/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)

(Omitted the repo and org)

This happens when git does not exit cleanly, but since it works 50% of the time I'm not sure that it's to do with my configuration.

To Reproduce This behaviour is flaky. I would say roughly 50% of my builds fail with this. All are created in the same way (they're dependabot updates). Rerunning the build usually fixes it, but this is costing me significant minutes in GHA.

Expected behavior 100% success rate.

Used Workflow

name: Update Cocoapods Dependencies

on:
  push:
    branches:
      - dependabot/npm_and_yarn/**
  pull_request:
    branches:
      - dependabot/npm_and_yarn/**

jobs:
  run:
    name: Run pod install
    runs-on: macos-latest
    steps:
      - uses: actions/checkout@v2

      - uses: c-hive/gha-yarn-cache@v1

      - run: yarn install --non-interactive --frozen-lockfile --network-timeout 100000

      - name: Cache pods
        uses: actions/cache@v1
        with:
          path: ios/Pods
          key: ${{ runner.os }}-pods-${{ hashFiles('**/Podfile.lock') }}
          restore-keys: |
            ${{ runner.os }}-pods-

      - name: Install Cocoapods Packages
        run: pushd ios && pod install --verbose && popd

      - uses: stefanzweifel/git-auto-commit-action@v4.11.0
        with:
          commit_message: Bump Cocoapods Packages
          branch: ${{ github.head_ref }}
stefanzweifel commented 3 years ago

[…] All are created in the same way (they're dependabot updates).

I assume this flaky behaviour started on March 1st? On that date, GitHub changed the permissions of the token issued to workflow runs started by GitHub Actions: Announcement blog post.

Since then, workflow runs which are started by Dependabot can't write to the repo. As stated in the blog post, you could use the pull_request_target-event to listen to in your workflow. We've covered this in the README, but I would not encourage to use it: It has it's own security risks and runs are not shown in the pull request status list.

You could solve this problem by writing another workflow that runs, when a Dependabot PR is merged to your default branch (You would somehow have to detect if the commit/PR was made by Dependabot). Or you could try using a personal access token to checkout the repository in your existing workflow (docs).

gerryfletch commented 3 years ago

Thanks for the response. Perhaps I misunderstood the details in the announcement blog post. This repository is not a fork, but I did come across those problems with dependabot merging the PR itself. Curious that this only happens some of the time.

I'll have a go at configuring a separate token. Thanks.