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)
As a correction (as I spent quite some time understanding what was going wrong) the correct
curl
to use is:So
Private-Token
instead ofX-Private-Token
andmygroup%2Fmyrepo
instead ofmygroup/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:Since by default the options
gitlabUrl = https://gitlab.com
andgitlabApiPathPrefix = /api/v4
, in your case, you would only need to setupGL_TOKEN
.As another note, if you still cannot access your project with this
curl
, trycurl --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 ahttps://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.
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
orhttps://gitlab.com/mygroup/myrepo.git
orhttps://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.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.