Required check is expected after automated push

In our workflow, we have an action that will push some modifications to a PR. As it is triggered with the default Github token, and not a personal access token, it is expected not to triggered the action again. All good here.

The issue is that we have a branch protection that makes the check required before merging. After the automated push, the PR still expects the check to pass, even though it is not triggered.
Is there a way to make the check not mandatory in the case the push is done via an action?

Here is a dummy repo that reproduce the issue: GitHub - loic-h/example-pending-github-status-check: Example of a failing workflow where a mandatory status check is waiting for an action that is never triggered.

So far, our only solution is authenticating with a PAT and having the actions run again, but it means for us running our checks twice basically, as the code pushed by the action is not concerned by the checks.

Thanks for your time and consideration!

Allowing required checks to be bypassed is problematic because it removes any confidence in the checks – they become effectively useless. That said, there’s an option available to you in this situation: Deploy Keys + pull_request_target.

A Deploy Key is an SSH key that has permissions to read (and write) in a specific repository and can trigger Workflows, pull_request_target is a special event that is triggered against the main branch after a Pull Request event.

note: You need a separate Workflow that lives on the main branch because a Workflow executed on a Pull Request does not have access to secrets.

  1. Create a new Deploy Key, enabling the “write” option
  2. Create a new Secret, with the name COMMIT_KEY and the value of the private key of the Deploy Key
  3. Create a new Workflow for the pull_request_target event
  4. Push your new Workflow to the main branch of your repository

Here’s an example of the Workflow you might use:

    types: [assigned, opened, synchronize]

    runs-on: ubuntu-latest
      - uses: actions/checkout@v2
          ssh-key: "${{ secrets.COMMIT_KEY }}"
          ref: ${{ github.event.pull_request.head.sha }}
      - run: date >> date.txt
      - name: Push new date
        uses: EndBug/add-and-commit@v7
          add: "date.txt --force"
          default_author: github_actions
          message: "chore: Add current time"

Any commit created by this Workflow will trigger other Workflows if they’re listening for pushes to the same branch – no need for a PAT, and no need to manually trigger the Workflows! :slight_smile:

You really really don’t want to do this.

I’d suggest looking into workflow_run:

Thank you both for your suggestions! Researching them brought a lot of insights.

Unfortunately, those are not solutions we can apply to our real life example, the main issue being both events running against the main branch, when we need them to run against the current one. Like jsoref said, we probably don’t won’t to do this and will look into alternative ways of implementation.

I think it might be worth clarifying this point: when we say that they run against the main branch, it means that GitHub Actions executes the contents of the Workflow from the main branch, however that doesn’t have any impact on your ability to interact with Pull Requests – you can checkout the Pull Request code (as shown in the example above) and push changes back to the repository which then trigger subsequent checks if you like. I have an example repository that shows this in action: pr-mpt/examples-workflow-trigger

The use-case you’re describing is very reasonable and achievable, if there are some aspects of the proposed solutions that you’re unsure about then I can help clarify.

As soon as you start dealing with pull_requests and pushing changes to repositories, you start inviting your repository to be hacked.

If I were going to implement this, I’d use perform all my testing in a disconnected repository clone. Yes, it’s annoying and may be slightly awkward, but it should be safer than the “obvious” paths.

I haven’t written this up, but you should at least read some content from GitHub Security Lab:

1 Like