Open eversC opened 6 years ago
@eversC thanks for this, and for the debugging so far. SCMSourceOwner implies that this is a Pipeline Multibranch project. Perhaps this feature is broken for that project type. Could you try creating a Freestyle project and see if you can trigger it with the same settings? If so, that'll be the problem. Thanks!
Incidentally, as a workaround you could look at using global authentication for the GitLab endpoint, as described in the README, rather than the secret token on a per-project basis. The code paths for that are different.
thanks @omehegan
Freestyle project with invalid token in gitlab hook correctly gives me a 401 "Invalid token" response
OK. I think you're right that this is a bug for Multibranch projects. It may be related to #704. Not sure how easy it will be to fix.
I am experiencing a similar issue, whereby connections to the jenkins gitlab-plugin "/project/" endpoint for a multi-branch-pipeline, are accepted without a TOKEN being passed.
This is despite the "Enable authentication for '/project' end-point" option being enabled.
I tried the suggested workaround of enabling "global authentication" by creating a jenkins service account, and using its token in the URL. This webhook works, but at the same time, not passing a TOKEN to the webhook URL also still works...
Is there anything else we can try, to get authentication enabled for a multi-branch-pipeline? (as reported earlier, typical "freestyle" projects work with auth, just not pipelines...)
thanks!
@MrFishFinger yeah, the more I think about this, the more I see why this is likely a bug just in multibranch projects. The reason is that multibranch jobs do not receive or process any of the webhook data from GitLab. Instead, triggering a multibranch job just causes Jenkins to perform branch indexing and then trigger builds accordingly from there. I want to see this change, but I don't really know how to go about it. But this raises a security concern we hadn't considered. I'll have to see what else can be done.
This issue seems to be fixed with #1544 in release 1.7.16
Context
Problem description
I'm trying to get the simple "secret token" auth working with multibranch declarative pipelines on my gitlab webhooks (I use google auth on my Jenkins instance, and don't want to create any users for this, just yet)
The webhooks (all "Push Hook") I've got set up seem to be working fine in the sense that they fire the correct project; the URLs I've got defined in the gitlab webhooks are of the format:/project/
It's the "secret token" part that's not being checked, regardless of what I specify in the gitlab webhook. Checking the details of webhooks that have fired shows the "X-Gitlab-Token" header being sent correctly.
an example snippet from one of my declarative pipelines:
Once this pipeline has run for a project, I can see all the config settings showing correctly in the "View Configuration" page of the project/branch in Jenkins.
So from what I can see, everything looks okay.
I added a gitlab-plugin log recorder, and can see entries such as:
"Jan 04, 2018 11:11:57 PM FINE com.dabsquared.gitlabjenkins.webhook.build.PushBuildAction Notify scmSourceOwner [project-name] about changes for [git-repo]"
doing some quick digging (and from log entries), e.g. in https://github.com/jenkinsci/gitlab-plugin/blob/master/src/main/java/com/dabsquared/gitlabjenkins/webhook/build/PushBuildAction.java suggests the project is an instance of SCMSourceOwner, as opposed to an instance of Job. The former results in a SCMSourceOwnerNotifier which doesn't seem to use secretToken, whereas the latter results in a TriggerNotifier which DOES use secretToken.
So is it correct that my projects are instances of SCMSourceOwner (and what does that mean?), and to get the secretToken functionality working, do I need to switch it to a Job, somehow, or will I have some configuration incorrectly set, somewhere?