gitlab: 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?

About this issue

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

Most upvoted comments

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.

esciara on Oct 21, 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.

pvdlg on Jan 15, 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.

That returns a 401 error indicating the token set in GH_TOKEN doesn’t allow to access the GitLab API or that your configuration for the API url is wrong.

pvdlg on Jan 15, 2019