Missing input "github_token: ${{ secrets.GITHUB_TOKEN }}".

[polina-c]

My repo: https://github.com/flutter-chat-dev/tic_tac_toe

Error: https://github.com/flutter-chat-dev/tic_tac_toe/actions/runs/5135214398/jobs/9240329007

Workflow:

name: Run layerlens.

on:
  push:
    branches: [ main]

jobs:
  generate_diagrams:
    runs-on: ubuntu-latest

    steps:
    - name: clone the repo
      uses: actions/checkout@v3

    - name: install Flutter sdk
      uses: subosito/flutter-action@48cafc24713cca54bbe03cdc3a423187d413aafa
      with:
        channel: 'stable'

    - name: version
      run: dart --version

    - name: dart pub get
      run: dart pub get

    - name: generate
      run: dart run layerlens

    - name: Commit files
      run: |
        echo ${{ github.ref }}
        git add .
        git config --local user.email "41898282+github-actions[bot]@users.noreply.github.com"
        git config --local user.name "github-actions[bot]"
        git commit -m "CI: Automated layerlens push" -a | exit 0

    - name: Push changes
      if: github.ref == 'refs/heads/main'
      uses: ad-m/github-push-action@df39337088a4cf2782a73f221bbd33f90e3e091d
      with:
        github_token: ${{ secrets.GITHUB_TOKEN }}

Will appreciate help!!!

[ZPascal]

Hi @polina-c, I'll check that. Do you've tried it with the corresponding ad-m/github-push-action@master version?

[polina-c]

just checked: https://github.com/flutter-chat-dev/tic_tac_toe/actions/runs/5135574184/jobs/9241187446

The issue is different:

remote: error: GH006: Protected branch update failed for refs/heads/main.        
remote: error: At least 1 approving review is required by reviewers with write access.        

Yes, I want approval on main branch from people.
Is it possible to configure the branch to require approvals for people, but not for actions?

[ZPascal]

@polina-c Is force push an option?

[polina-c]

Yes, force push is allowed in the repo.
Are you saying I can force push in action? How I should update the workflow for this?

[polina-c]

@ZPascal ?

[ZPascal]

@polina-c That was just a guess whether it might work to bypass the branch protection rule. I am in the process of testing this right now. I will report when I have the results of my test.

[ZPascal]

@polina-c I've got a solution for you. You need a personal access token, it's necessary to set up the branch protection rule "Allow force pushes" to "Specify who can force push" and set up your or own user. It's also better to specify the force_with_lease parameter of the push action to true.

FYI: I've tested the solution inside this action run.

[polina-c]

Thank you!

Can you outline exact steps in your README.md?

[ZPascal]

@polina-c Sure, I'll adjust the documentation as a follow-up.

[ZPascal]

@polina-c Can we close this issue?

[polina-c]

I checked the documentation. Is it correct understanding that I am missing 'force_with_lease: true' in my script?
Let me try it.

[polina-c]

It seems personal access token is necessary. Any chance you can outline or link steps?
There are different types of access tokens in github. How exactly they should be created to make it working?

[polina-c]

In your test script dummy2 (that succeeded) still uses secrets.GITHUB_TOKEN, that is not custom access token, but is standard githib job access token.

https://github.com/ZPascal/test_origin_push_action/blob/main/.github/workflows/test.yml

Am I missing something?

[ZPascal]

Hi @polina-c,

I checked the documentation. Is it correct understanding that I am missing 'force_with_lease: true' in my script?
Let me try it.

This relates to your case. I had the problem that it was not possible for me to push directly to the repository, and I had to use the force_with_lease option.

It seems personal access token is necessary. Any chance you can outline or link steps?
There are different types of access tokens in github. How exactly they should be created to make it working?

Yes, that is correct, the PAT is necessary for your case. I will create documentation on how to create the token and also publish it in the documentation of the action itself as a follow-up.

In your test script dummy2 (that succeeded) still uses secrets.GITHUB_TOKEN, that is not custom access token, but is standard githib job access token.
https://github.com/ZPascal/test_origin_push_action/blob/main/.github/workflows/test.yml
Am I missing something?

Yes, that's right, I've used the classical token to perform a checkout of the repository, but I've used the PAT for the push itself.

If you have any further questions, please feel free to ping me.

[nriss]

Hi @ZPascal,

I think we've got the same problem there:
https://github.com/ansforge/IG-documentation/actions/runs/5455795460

We created an organization secret that isn't recognized apparently

[ZPascal]

Hi @nriss,

it's necessary that you've specified the corresponding custom token inside triggered workflow file or forward it to the other action inside the other repository. The default token ${{ secrets.GITHUB_TOKEN }} can only be used inside the triggered repository.

It's in general necessary that you set up an custom personal access token and specify it as described in the following code sample or forward it to the executed GH Action at the end.

    - name: Push changes
      if: github.ref == 'refs/heads/main'
      uses: ad-m/github-push-action@master
      with:
        github_token: ${{ secrets.PAT }}

[zhu-xiaowei]

https://github.com/ansforge/IG-documentation/actions/runs/5455795460

Hi～ I also meets this error, after I try to add PAT token when checkout, the push action is works well.

- uses: actions/checkout@v3
  with:
    ref: main
    token : ${{ secrets.PAT }}

and also i tried without setting PAT token in actions/checkout@v3 the ad-m/github-push-action@master action also will be failed with above error. @ZPascal this might be the root cause of the problem, might consider adding it to README.md

[ZPascal]

@zhu-xiaowei I'm a bit surprised, because I've tested it my test case the mixture between default token and PAT. I'll set up a new test case to further investigate the topic.

[zhu-xiaowei]

@ZPascal the Test1 with default GitHub token is failed with above error, and the Test2 with PAT is successful, the only difference of this two test is the token set in the checkout action.

for more background information:

1. The protected branch is main, and checked Require a pull request before merging
2. Added Allow specified actors to bypass required pull requests to my account.
3. Checked Require status checks to pass before merging
4. Unchecked Do not allow bypassing the above settings
5. The PAT is generated in my account with required permission, and tested to push to main branch is successful in terminal.

So, I think there may be some difference between my settings and your test case settings.

[zhu-xiaowei]

@ZPascal I also test this case for only set the PAT as token in checkout@v3 action, that is also successful, and I found the description of token in checkout action：

# Personal access token (PAT) used to fetch the repository. The PAT is configured
# with the local git config, which enables your scripts to run authenticated git
# commands. The post-job step removes the PAT.

So, I think the reason is that the checkout action will set the PAT to the local git configuration and allow the following git commands to authenticate with the correct permissions. I don't know if github-push-action has changed the local git configuration with the set PAT token and made it allow authorization.

[ZPascal]

Hi @zhu-xiaowei,

So, I think there may be some difference between my settings and your [test case](https://github.com/ZPascal/test_origin_push_action/actions/runs/5165266723/workflow#L49) settings.

Yes, there is a difference. Unfortunately, I failed to specify the right branch inside my test case, which was in the end not protected. Especially for the --force-with-lease flag we need the corresponding valid branch already inside the checkout action.

I don't know if github-push-action has changed the local git configuration with the set PAT token and made it allow authorization.

The github-push-action does not overwrite the local git config. It only adjusts the used URL.

FYI: I've already documented the corresponding hint inside the documentation.