semantic-release(/git) not using GH_TOKEN

[imduchy]

We're trying to push a commit to the protected master-test branch with Github Actions after a pull request is merged (on push to master-test). I generated a personal token with appropriate access to our repo (having an admin role) but noticed that the token is probably not being used (in Personal access token settings on GitHub).

I went through the documentation, followed each step, but still can't make it work. I've also tried to use GIT_CREDENTIALS env variable, without success.

We're using:

• "semantic-release": "^17.0.4"
• "@semantic-release/git": "^9.0.0"

release.config.js

/* eslint-disable @typescript-eslint/no-var-requires */

module.exports = {
	branches: [
		'master-test'
	],
	plugins: [
		"@semantic-release/commit-analyzer",
		"@semantic-release/release-notes-generator",
		"@semantic-release/npm",
		["@semantic-release/github", {
			"assets": ["dist/**"]
		}],
		["@semantic-release/git", {
			"assets": ["dist/**/*.{js,css}", "docs", "package.json"],
			"message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
		}]
	  ],
}

action setup

- name: Semantic Release
run: yarn semantic-release #runs "semantic-release --debug"
env:
  NODE_ENV: production
  GH_TOKEN: ${{ secrets.GH_TOKEN }}
  GITHUB_TOKEN: ${{ secrets.GH_TOKEN }}
  NPM_TOKEN: ${{ secrets.NODE_AUTH_TOKEN }}
  NODE_AUTH_TOKEN: ${{ secrets.NODE_AUTH_TOKEN }}

output from the job

shortMessage: 'Command failed with exit code 1: git push --tags https://github.com/xxx/xxx.git HEAD:master-test',
command: 'git push --tags https://github.com/xxx/xxx.git HEAD:master-test',
exitCode: 1,
signal: undefined,
signalDescription: undefined,
stdout: '',
stderr: 'remote: error: GH006: Protected branch update failed for refs/heads/master-test. \n' +
"remote: error: You're not authorized to push to this branch. Visit https://help.github.com/articles/about-protected-branches/ for more information. \n" +
'To https://github.com/xxx/xxx.git\n' +
' ! [remote rejected] HEAD -> master-test (protected branch hook declined)\n' +
"error: failed to push some refs to 'https://github.com/xxx/xxx.git'",
failed: true,
timedOut: false,
isCanceled: false,
killed: false,

[pvdlg]

What make you think it's related to not using GH_TOKEN?
The error mention the branch is protected, so I guess it's related to a verification configured in the protected branch that make the commit failed.

Have you tried to push a commit to a protected branch with the same settings outside of semantic-release?

[imduchy]

@pvdlg We were trying to bypass the protection with a personal access token and couldn't achieve it.

Now we managed to do it by setting a token in actions/checkout. This has fixed the problem for us. However, I'm a little bit concerned about this 'fix' as it seems we give elevated permissions to every step running in the job.

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

Also, we no more need the GH_TOKEN: ${{ secrets.GH_TOKEN }} in our semantic-release step to make it work with the above-mentioned fix. The bellow example works without any problem now.

- name: Semantic Release
   run: yarn semantic-release
   env:
     NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

we use these plugins

const plugins = [
    '@semantic-release/commit-analyzer',
    '@semantic-release/release-notes-generator',
    '@semantic-release/changelog',
    '@semantic-release/npm',
    '@semantic-release/git',
]

This makes me think that semantic-release wasn't using our GH_TOKEN before.

Any ideas of what we could oversee?

[pvdlg]

It seems the error happens based on how the repo was cloned... Not sure why.

If that helps here is how semantic-release interact handle repo authentication:

• Try to push to the repo with the repository.url configured in package.json
  • If that works use that URL and ignore GH_TOKEN
  • if that fails, transform the repository.url configured in package.json and insert the GH_TOKEN as basic auth

I don't know what GitHub is doing exactly when verifying permissions for protected branches nor what actions/checkout@v2 does that would change how the protected branches permissions are verified.

[pvdlg]

It seems the action set the token in .git/config: https://github.com/actions/checkout/blob/f858c22e963bc60bc9d01c3d105c52a45a7deb6e/src/git-source-provider.ts#L264

In semantic-release we don't do that as we don't want to leave a token behind in a file on the CI.
We do git push --tags https://x-access-token:<GH_TOKEN>@github.com/owner/repo.git

I don't know why the branch protection behave differently in those 2 cases. They should be equivalent.

[imduchy]

In semantic-release we don't do that as we don't want to leave a token behind in a file on the CI.
We do git push --tags https://x-access-token:<GH_TOKEN>@github.com/owner/repo.git

@pvdlg I just noticed that in our logs semantic-release outputs command: 'git push --tags https://github.com/{org}/{repo}.git HEAD:master-test' instead.

Might that be a problem? I can't see x-access-token:<GH_TOKEN> in our logs at all.

//EDIT:
That makes me think, we configuring repository.url, should the format be https://x-access-token:<GH_TOKEN>@github.com/owner/repo.git?

[pvdlg]

I just noticed that in our logs semantic-release outputs command: 'git push --tags https://github.com/{org}/{repo}.git HEAD:master-test' instead.

That's expected. As I explained earlier:

If that helps here is how semantic-release interact handle repo authentication:

• Try to push to the repo with the repository.url configured in package.json
  • If that works use that URL and ignore GH_TOKEN
  • if that fails, transform the repository.url configured in package.json and insert the GH_TOKEN as basic auth

Because actions/checkout@v2 sets the token directly in .git/config semantic-release can push without having to add the token to the URL.

That makes me think, we configuring repository.url, should the format be https://x-access-token:<GH_TOKEN>@github.com/owner/repo.git?

No. As explained earlier semantic-release already adds the token to the URL when necessary.

[rshaibakov]

@pvdlg I see myself having the same problem.

I can 't understand it:

if that fails, transform the repository.url configured in package.json and insert the GH_TOKEN as basic auth

Isn't basic auth this https://x-access-token: < GH_TOKEN>@github.com/owner/repo.git?

[pvdlg]

Isn't basic auth this https://x-access-token: < GH_TOKEN>@github.com/owner/repo.git?

yes it is. So? I don't understand what you are asking.

[cawolf]

@Duchynko provided a workaround, which also works in my repositories with protected branches:

Now we managed to do it by setting a token in actions/checkout. This has fixed the problem for us. However, I'm a little bit concerned about this 'fix' as it seems we give elevated permissions to every step running in the job.

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

Also, we no more need the GH_TOKEN: ${{ secrets.GH_TOKEN }} in our semantic-release step to make it work with the above-mentioned fix. The bellow example works without any problem now.

@pvdlg: any chance to look into this behaviour or at least add a documentation for it?

[anpa]

Setting persist-credentials: false in the checkout step seems to work as well:

- name: Checkout
   uses: actions/checkout@v2
   with:
      persist-credentials: false
- name: Release
   run: yarn semantic-release
   env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

According to the actions/checkout@v2 docs:

The auth token is persisted in the local git config. This enables your scripts to run authenticated git commands. The token is removed during post-job cleanup. Set persist-credentials: false to opt-out.

[alexkvak]

@anpa your answer really saved a lot of time! Huge thanks!