Github linting - Remote Rejected

Hi everyone,

I’ve just started developing a new feature for my app and I’ve noticed that the Github actions are failing.

It says something about the remote being rejected, but how ? Im super confused as I can see the workflow works when with the master branch, but with my new branch it fails the linting task.

@alexmachin1997,

What token are you using to authenticate in your workflow when pushing the modified workflow file? The GITHUB_TOKEN or a personal access token you created?

Im super confused as I can see the workflow works when with the master branch, but with my new branch it fails the linting task.

Did you use the same token to authenticate in the workflows of the two branches?

As mentioned in the logs, to create or update workflow file, the scopes of the authentication token must have “workflows” permission.
scopes

The GITHUB_TOKEN does not have “workflows” permission.
So you need to use a personal access token with “workflows” permission in your workflow, if you want to create or update workflow files in the workflow run. But you should avoid creating recursive workflow runs.

I just built a work around - although its not very fun to do from developer standpoint, it does work…

Hi Brightran,

Yeah I used the secrets.GITHUB_TOKEN for both the master branch and feature.

Shame you can’t have one token and it works for everything, they need to change this as it’s a real pain especially as most people will want actions on feature branches.

You mentioned you can create a secret token, would this allow the bot to commit to the branch on both the master any any feature branches ?

Thanks,

Alex

@alexmachin1997,

Shame you can’t have one token and it works for everything, they need to change this as it’s a real pain especially as most people will want actions on feature branches.

No, I don’t think so.

The GITHUB_TOKEN is automatically generated by GitHub when the workflow is triggered to run. Anybody (include the outside users) who can trigger workflows in your repository is able to use the GITHUB_TOKEN to do everything which has been allowed in the access scopes.

If the GITHUB_TOKEN has too many access scopes or the full scopes, this may present some security risks.
The GITHUB_TOKEN is only available to the current repository where the workflow is running, and some of the permissions are not included in this token’s access scopes. This is a security policy aimed at avoiding security risks as much as possible in your repository.

You mentioned you can create a secret token, would this allow the bot to commit to the branch on both the master any any feature branches ?

Of course. Anyone who are using this PAT can push commits to any branch in your repository, as long as the access scopes have included the related permissions.

Im actually really annoyed by this limitation, I get why they have done it but come on.

I hope this get’s resolved, surely people have been complaining.

I think a nice and easy solution would be to generate a token per branch.

In the mean time is it possible to disable this for the action or is it a baked in secuirty feature for all the actions ?

@alexmachin1997,

Currently, the only available way is to create a new PAT that has “workflows” permission.

In the mean time is it possible to disable this for the action or is it a baked in secuirty feature for all the actions ?

Once a PAT is created, you can’t dynamically change its access scopes when using it in the workflow.

I think a nice and easy solution would be to generate a token per branch.

If your projects really need this feature, I recommend that you can directly report a feature request here. That will allow you to directly interact with the appropriate engineering team, and make it more convenient for the engineering team to collect and categorize your suggestions.

Hi Brightran,

I’ve sent some feedback via the ljnk you provided.

Quick update on what’s happened recently. So I modified the a workflow file and now my actions are working, Im really confused why this has happened. How can modifying a file make it work ? Does a new token get generated when a workflow file is modified.

@alexmachin1997,

To create a personal access token (PAT) used in the workflows, you need to manually do all the steps below (more details, see here):

  • Navigate to ‘Personal settings’ > ‘Developer settings’ > ‘Personal access tokens’ page.

  • Click the ‘Generate new token’ button, set token name, and select scopes you need.

  • After selecting scopes, click the ‘Generate token’ button to save the settings. The new token generated, copy the token to your clipboard.

  • Open the web page of the repository that contains the workflows you want to run. Navigate to ‘Settings’ > ‘Secrets’ page to add a new secret in the repository (more details, see here).

  • Click the ‘New secret’ button, set the secret name, and paste the copied token from your clipboard to as the value of the new secret. Click the ‘Add secret’ button to save the new secret.

After, above steps, you can use the expression “secrets.<SECRET_NAME>” to access and use the new PAT in the workflow in the current repository.
For example,

- name: Checkout
  uses: actions/checkout@v2
  with:
    token: ${{ secrets.MY_GITHUB_PAT }}

Of course, you also can add the new PAT as an organization secret that can be used by all the repositories in the organization.

The modification of the source files, include the workflow files, will not automatically update or generate a new PAT. Generally there is no relationship between them. And the modification of the files also does not affect the secrets.

So I spoke to a someone on twitter and it turns out the issue wasn’t related to tokens.

The workflow action was trying modify my workflow .yml file, I just needed to tell prettier and eslint to ignore my .github folder.

Now it work’s as expected.

1 Like

@alexmachin1997,

Yes, the action “samuelmeuli/lint-action” you are using in your workflow is used to lint errors and auto-fix in the files from the current commit or PR. By default this action will check all the files (include the workflow files) of the current checked out commit in the working directory on the runner. After fixing the files, it will auto-push the modified files to remote GitHub repository authenticating with the GITHUB_TOKEN by default.

As I have mentioned above, for other files in the repository, the GITHUB_TOKEN has enough scopes to change and push them to the remote. For the workflow files, the authentication token must have “workflows” permission, but the GITHUB_TOKEN does not have this permission.

So, to avoid this problem, there are two workarounds:

  1. As you shared, if you do not want the “samuelmeuli/lint-action” action to check the workflow files, you can set this action to ignore all the workflow files. And use the GITHUB_TOKEN to authenticate.

  2. If you want the action to check all the files, you need to create a personal access token that contains “workflows” permission to authenticate on this action.

However, the second workaround may create recursive workflow runs. So I think the first one you shared should be the best way.

Events triggered by the GITHUB_TOKEN will not create a new workflow run. This prevents you from accidentally creating recursive workflow runs.

As mentioned, a PAT us not required to do this securely - my repo works great with forked PR with no security implications since only the code running from master is ever exposed to secrets.

So I’ve setup linting for my portfolio projects, and now I’m getting the same error message as before even though I’ve to eslint and prettier to ignore the .yml files.

ld