Failed step "verifyConditions" with EINVALIDGLTOKEN and EGITNOPERMISSION error

I have been trying to figure this out for quite sometime now and i have tried all possible ways that i can think of.

The build is always failing with the following logs

[8:38:37 AM] [semantic-release] › ℹ  Running semantic-release version 15.13.3
[8:38:37 AM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/gitlab"
[8:38:37 AM] [semantic-release] › ✔  Loaded plugin "analyzeCommits" from "@semantic-release/commit-analyzer"
[8:38:37 AM] [semantic-release] › ✔  Loaded plugin "generateNotes" from "@semantic-release/release-notes-generator"
[8:38:37 AM] [semantic-release] › ✔  Loaded plugin "publish" from "@semantic-release/gitlab"
[8:38:37 AM] [semantic-release] › ✔  Run automated release from branch master
[8:38:38 AM] [semantic-release] › ✔  Allowed to push to the Git repository
[8:38:38 AM] [semantic-release] › ℹ  Start step "verifyConditions" of plugin "@semantic-release/gitlab"
[8:38:38 AM] [semantic-release] [@semantic-release/gitlab] › ℹ  Verify GitLab authentication (https://gitlab.com/mygroup/myrepo.git/api/v4)
[8:38:38 AM] [semantic-release] › ✖  Failed step "verifyConditions" of plugin "@semantic-release/gitlab"
[8:38:38 AM] [semantic-release] › ✖  EINVALIDGLTOKEN Invalid GitLab token.
....
[8:38:38 AM] [semantic-release] › ✖  EGLNOPERMISSION The GitLab token doesn't allow to push on the repository mygroup/myrepo.
....

weather i set the variables in gitlab CI/CD settings or in the .releaserc or in the gitlab.ci.yml all of these didn’t work i even tried to put "verifyConditions": [], in the @semantic-release/gitlab options in the .releserc file

I have referred to this issue #19 but couldn’t get much and in my case it’s simply a project under a group not under a subgroup

any ideas on how i can get this work?

Issue Analytics

State:
Created 5 years ago
Reactions:3
Comments:18 (7 by maintainers)

Top GitHub Comments

2reactions

esciaracommented, Oct 21, 2019

In order to verify the permission semantic-release will run the equivalent of curl --header "X-Private-Token: ${GH_TOKEN}" https://gitlab.com/mygroup/myrepo.git/api/v4/projects/mygroup/myrepo.

As a correction (as I spent quite some time understanding what was going wrong) the correct curl to use is:

curl --header "Private-Token: ${GL_TOKEN}" ${GL_URL}${GL_PREFIX}/projects/mygroup%2Fmyrepo

So Private-Token instead of X-Private-Token and mygroup%2Fmyrepo instead of mygroup/myrepo. See GitLab’s API doc on personal access tokens and GitLab’s API doc on namespaced path encoding. As an aside, one should read ${GL_TOKEN}, which is the token for GitLab instead of ${GH_TOKEN}, which is the token for GitHub.

In this particular case, the correct curl would be:

curl --header "Private-Token: <your_access_token>" https://gitlab.com/api/v4/projects/mygroup%2Fmyrepo

Since by default the options gitlabUrl = https://gitlab.com and gitlabApiPathPrefix = /api/v4, in your case, you would only need to setup GL_TOKEN.

As another note, if you still cannot access your project with this curl, try curl --header "Private-Token: <your_access_token>" https://gitlab.com/api/v4/projects. If this time you get a response, if you also are behind a reverse proxy, it might be that your reverse proxy is not correctly configured, and decodes the %2F into a /, hence forwarding a https://gitlab.com/api/v4/projects/mygroup/myrepo, which will result in a {"error": "404 Not Found"}.

See this GitLab issue for more details, including a correction of reverse proxy configuration. Careful about the solution provided, it might not be a full proof secure solution of Nginx revers proxy, see this Nginx ticket for more info and this stackoverflow entry for a potentially more secure solution.

1reaction

pvdlgcommented, Jan 15, 2019

I understood that you made this replacement in the logs. That doesn’t change my point though.

https://gitlab.com/grainer-core/rc-api.git or https://gitlab.com/mygroup/myrepo.git or https://gitlab.com/anything/anything.git doesn’t look like the URL of a GitLab instance. It look like the URL of a repo.

This is why I pointed you to the documentation explaining that GL_URL has to be set with the URL of you GitLab instance while it seems you put your repo URL in there.