Gitlab-plugin: Failed to update Gitlab commit status for project. HTTP 401 Unauthorized

[angelosanramon]

Issue

Failed to update Gitlab commit status for project. HTTP 401 Unauthorized

Context

• Gitlab plugin version: 1.4.2
• Gitlab version: GitLab Enterprise Edition 8.11.5-ee b7548a4
• Jenkins version: 2.25
  

  Logs & Traces

Started by GitLab push by Angelo San Ramon
[EnvInject] - Loading node environment variables.
Building in workspace /Users/jenkins/.jenkins/jobs/test/workspace
 > /usr/bin/git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > /usr/bin/git config remote.origin.url https://gitlab.corp.apple.com/sales-devops2/pst_apps-ansible.git # timeout=10
Fetching upstream changes from https://gitlab.corp.apple.com/sales-devops2/pst_apps-ansible.git
 > /usr/bin/git --version # timeout=10
using GIT_ASKPASS to set credentials 
 > /usr/bin/git fetch --tags --progress https://gitlab.corp.apple.com/sales-devops2/pst_apps-ansible.git +refs/heads/*:refs/remotes/origin/* +refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*
skipping resolution of commit remotes/origin/master, since it originates from another repository
 > /usr/bin/git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > /usr/bin/git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 19796fb6ba4e2b2729144b052f3501250995878d (refs/remotes/origin/master)
 > /usr/bin/git config core.sparsecheckout # timeout=10
 > /usr/bin/git checkout -f 19796fb6ba4e2b2729144b052f3501250995878d
 > /usr/bin/git rev-list 19796fb6ba4e2b2729144b052f3501250995878d # timeout=10
Failed to update Gitlab commit status for project '15612': HTTP 401 Unauthorized
Failed to update Gitlab commit status for project '15612': HTTP 401 Unauthorized
Finished: SUCCESS

Problem description

I created a post-build actions to "Publish build status to GitLab commit", but I am getting a 401 Unauthorized message when the build is triggered. The build return successful, the post-build message shows 401. I am pretty sure the Gitlab token I am using has Owner permission on the project.

[omehegan]

@angelosanramon The 401 error is almost almost always caused by lack of permissions in GitLab. The user Jenkins is connecting as must be at least Developer on the specific project you want to post build status to. Please check that.

Also, looking at the GitLab logs when this happens may offer more information.

[abhisku]

I am facing the same issue. Does your answer means that I have to create a member in GitLab with name Jenkins ?

[omehegan]

It does not have to be a user named Jenkins, but you must create a user in GitLab, give that user access to your projects, and configure the Jenkins plugin accordingly. This is documented here: https://github.com/jenkinsci/gitlab-plugin#configuring-access-to-gitlab

[abhisku]

Thanks for your reply. It is working for me. There was some issue with the permission.

[acohen716]

If we have our CloudBees Jenkins set up in a way that is shared across the company with folders for the different groups will we be able to get the build status working? Because I can't seem to get it to work, I seem to also get the 401 Unauthorized but my GitLab API Token credential is set up for my specific group/folder on the Jenkins instance vs at the master level.

Why is the API token used vs Deploy Keys? We're able to set up our own Deploy keys that work within our folder/group on the shared Jenkins instance but it seems like our own API token on the shared instance doesn't work.

[omehegan]

@acohen716 AFAIK the setup you are describing should work. If it does not, I would first suggest you check the GitLab logs to see if it tells you more specifically why it is giving a 401. Also let me know what version of GitLab you are using.

I don't know what a Deploy Key is. When I look that up in the GitLab doc, it appears to be a restricted key for cloning and pushing to a repo, to be used by deploy processes/jobs. This is unrelated to the GitLab API, which is what we need to access to tell GitLab whether a job succeeded or failed.

[acohen716]

@omehegan thanks for your response. I will have our GitLab admin see if they can take a look at the GitLab logs. I'd imagine that our GitLab connection we are using within Enterprise Jenkins doesn't have Developer access to each and every project within Enterprise GitLab and when a GitLab API Token is defined within my project folder I don't think the plugin picks up that Token and instead uses the top level Enterprise Jenkins defined connection/token.

The version of GitLab we're using is "GitLab Community Edition 9.5.1" and the version of Jenkis we're using is "CloudBees Jenkins Enterprise 2.7.22.0.1".

Ok, I understand why a deploy key wouldn't work for this then, thanks for the explanation.

[omehegan]

@acohen716 make sure you have followed the directions here: https://github.com/jenkinsci/gitlab-plugin#configuring-access-to-gitlab Specifically, you need to:

1. Create a user in GitLab
2. Get that user's API token
3. Give that user Developer access to each GitLab project/repo you want to be able to send build results to
4. Configure that user's API key in Jenkins

My practice was to create a single Jenkins user in GitLab and give that user access to individual projects that Jenkins was building and sending results back to (as opposed to giving it global access to all projects).

[acohen716]

@omehegan let me try to clarify further. We have an enterprise-wide Jenkins available with many users in various groups that are separated by folder and users in specific groups only see their own folder. Additionally, each folder has its own credentials. We also have an enterprise-wide GitLab instance that has many users in various groups.

We'd like to allow all Jenkins projects to be able to publish build status back to their own group's GitLab projects but it seems like the top level Jenkins configuration is the GitLab connection/API token that's used for publishing build status versus at the Jenkins group/folder credentials level.

So, for example, my group has both a GitLab group on our enterprise GitLab instance and a Jenkins group/folder on our enterprise Jenkins instance. I have developer access to the GitLab projects that we build in our Jenkins jobs and I've grabbed the API token. I go into our Jenkins folder and am able to add a GitLab API token (but there's no Test button - I'm thinking because this isn't the correct top level Jenkins GitLab API token credential and instead just for my folder). When I try to publish build status I get a 401 error because I believe it's not using my API token and instead using the top level API token defined at the Jenkins instance level vs at the group/folder level.

[omehegan]

@acohen716 OK, now I understand... I think. A possible workaround for you would be to create multiple GitLab connections at the global Jenkins level - http://JENKINS_URL/configure You can give each one a different name, point them to the same URL, and add a different API key to each one. Then, in your jobs or at your folder level, you should be able to specify the appropriate GitLab connection, which will also use the appropriate API key.

I maintain that you should be creating dedicated users in GitLab for this, though, not using your personal/developer user's API key. This just seems like a better practice.

[acohen716]

@omehegan So it looks like the configure page has been restricted to only certain people to view. Though I can see a configure page for my group/team-folder. ie http://JENKINS_URL/job/FOLDER but there is no option to create a GitLab connection in there. The only place I can create an API token is in the credentials of my group but then it doesn't seem like I can use it in my job for the GitLab connection.

I agree we'd have a dedicate service account user in GitLab but one step at a time :-).

[omehegan]

@acohen716 yes, I suppose you will need to work with someone who has admin access to your Jenkins install to handle configuring at least one GitLab connection with the right API key. Keep in mind that this is only used for sending build results to GitLab, if you're wondering how clones might already be working... clones use the SSH key.

[acohen716]

@omehegan But it's an enterprise Jenkins and an enterprise GitLab setup so there isn't a single GitLab API token that we'd use in the enterprise Jenkins instance to publish build status to all GitLab projects.
Is the plugin able to use credentials at the project level instead of the jenkins install level?

[omehegan]

As far as I'm concerned it doesn't matter whether it's Jenkins or GitLab enterprise or open source/free etc. The setup is the same. You can use more than one API key, but in Jenkins they will have to be set up at the global level as separate GitLab "connection" resources, one per key you want to use. Name them accordingly. Then, at the project level, you can select the connection that has the credentials you want to use.

And there's still no technical reason why you can't use one GitLab API key for all Jenkins API calls.

[acohen716]

@omehegan Ok, so it sounds like there are 2 options:

1. Have the Jenkins administrators add a GitLab connection (API key) upon requests from groups/projects that would like their build status published to GitLab.

2. Set up a single GitLab account with Developer access to ALL projects on the enterprise GitLab instance for publishing build status?

Did I miss anything here?

[omehegan]

@acohen716 that's right. For solution 1, someone will need to create a corresponding GitLab user and get its API key for each team. For solution 2, the user can be limited to API access only, and only for projects that are actually built by Jenkins, if you want to contain it somewhat. But that API access would still allow someone to do destructive things in theory if it were misused. But the plugin is not capable of that. Further, if your Jenkins is locked down such that ordinary users cannot create/edit that API key credential in Jenkins, those users would not be able to see or steal the key.

[bbodenmiller]

@omehegan would it be possible to update the plugin to support a Jenkins project level defined credential? Relying on Jenkins admins as opposed to Jenkins project owners to add the API keys doesn't scale well.

Also you mention giving a GitLab user API only access, how can you do that?

[acohen716]

@omehegan I agree with @bbodenmiller and would like to get your thoughts on his questions as well.

[omehegan]

It is possible, but at this point we are discussing a new feature in a ticket that was closed almost a year ago. It would be better to open a new issue to request this feature. I can't make any promises about when or if it would be implemented, unless you can provide a PR.

In terms of giving a user API-only access, I'm not 100% sure how you configure that in GitLab, and it would vary depending on the version you are using. I would work with them to get an answer to that.

[acohen716]

Ok, I've opened a new issue for the feature request. We'll look into the API-only access. Thanks!

[ghost]

I had the same issue and got it solved following this procedure: https://github.com/jenkinsci/gitlab-plugin#configuring-access-to-gitlab