No longer works without secret token

[kuhnroyal]

The new plugin version 1.5.2/1.5.3 no longer works without a configured secret token compared to 1.5.1.

No events trigger a build anymore, only a manual scan does.
Reverting to 1.5.1 restores old behavior.

Jan 04, 2021 7:22:21 PM WARNING hudson.init.impl.InstallUncaughtExceptionHandler handleException
Caught unhandled exception with ID bed65132-413c-4a4e-80a9-00e4d02567b4
java.lang.Exception: Expecting a valid secret token
	at org.kohsuke.stapler.HttpResponses.error(HttpResponses.java:91)
	at io.jenkins.plugins.gitlabbranchsource.GitLabWebHookAction.doPost(GitLabWebHookAction.java:75)

[dcendents]

Found out I had the same problem today the hard way

Also if I set a token (which is obviously better), then I have to manually update all the existing webhooks in gitlab.

The following documentation seems to be wrong:

If you are a old plugin user and did not set a secret token previously and want secret token to applied to the hooks of your existing jobs, you can add the secret token and rescan your jobs. Existing hooks with new secret token will be applied.

Edit: However if I edit the project configuration and save it (changed the description) then the webhook is re-created correctly.

[gwaldvogel]

Edit: However if I edit the project configuration and save it (changed the description) then the webhook is re-created correctly.

This did the trick for me, I didn't even change the description and it worked.

[kuhnroyal]

I tried this but it only worked once, no triggers on events afterwards.

[TBBle]

Looks like https://issues.jenkins.io/browse/JENKINS-64529 is the same problem.

[bruceforlearn]

Found out I had the same problem today the hard way

Also if I set a token (which is obviously better), then I have to manually update all the existing webhooks in gitlab.

The following documentation seems to be wrong:

If you are a old plugin user and did not set a secret token previously and want secret token to applied to the hooks of your existing jobs, you can add the secret token and rescan your jobs. Existing hooks with new secret token will be applied.

Edit: However if I edit the project configuration and save it (changed the description) then the webhook is re-created correctly.
I set token on secret like this,but error Hook executed successfully but returned HTTP 401

[TBBle]

It seems this was a known, deliberate change per #91 (comment). But the 1.5.2 release notes marked it as a fix, rather than a breaking-change new feature.

It appears that the migration plan, per https://github.com/jenkinsci/gitlab-branch-source-plugin/pull/91/files#r428530619, was to "trigger rescan of the org", I'm not sure what that means. I suspect the documentation "you can add the secret token and rescan your jobs" is a reference to this, but was a mistake, and it meant "rescan your organisation". Possibly that relates to the "Folder Organization", aka "GitLab Group" item type?

Either way, the migration approach only works if the plugin is managing the webhooks.

For a plugin-managed webhook, to update a Multibranch Pipeline job I think it should be enough to merely open the job and save it (without changes) and it should update the webhook with a secret token. I assume a Folder Organization has a "rescan" button somewhere, and that is in-effect doing the same thing, saving each of its generated Multibranch Pipeline jobs without changes.

[Stikus]

@TBBle If I understood correctly your issue #107 - we already have one secret token for Gitlab connection - so why we should create another for webhooks?

[TBBle]

I'm not sure what #107 has to do with this? #107 is talking about per-user API tokens so that this plugin can take actions as a user (or users) on GitLab, such as scanning for updates to projects or modifying GitLab configuration.

This issue is about the secret token in the GitLab webhook, so that when GitLab contacts Jenkins, Jenkins knows that a Jenkins administrator set that up, rather than it just being some random person generating build requests.

[Stikus]

Maybe I'm wrong, but here is my instance configuration (plugin part):

So my secret token is already set? What should I do to fix this issue? Resave my jobs?

[TBBle]

Yes, resaving each of your jobs should do it.

The secret token we're talking about in this ticket is not the Personal Access Token on this screen though. This issue is about the one in the job configuration (as each job has its own secret token), and resaving the job will update the GitLab Web Hook with the token, since you have "Manage Web Hooks" enabled here.

[kuhnroyal]

I tried to rescan my group folder jobs with 1.5.3 but getting a Nullpointer there:

ERROR: [Fri Jan 29 10:13:30 UTC 2021] Could not fetch sources from navigator io.jenkins.plugins.gitlabbranchsource.GitLabSCMNavigator@3d99fd21
java.lang.NullPointerException
	at io.jenkins.plugins.gitlabbranchsource.GitLabSCMNavigator.visitSources(GitLabSCMNavigator.java:274)
	at jenkins.branch.OrganizationFolder.computeChildren(OrganizationFolder.java:542)
	at com.cloudbees.hudson.plugins.folder.computed.ComputedFolder.updateChildren(ComputedFolder.java:278)
	at com.cloudbees.hudson.plugins.folder.computed.FolderComputation.run(FolderComputation.java:165)
	at jenkins.branch.OrganizationFolder$OrganizationScan.run(OrganizationFolder.java:1033)
	at hudson.model.ResourceController.execute(ResourceController.java:97)
	at hudson.model.Executor.run(Executor.java:429

[TBBle]

@kuhnroyal I'd raise that as another bug report, so it's clearly visible as a bug report.

However, it's possible this was fixed by #105, which was after the 1.5.3 release.

One option would be to try the auto-build of the plugin from master, e.g. https://repo.jenkins-ci.org/incrementals/io/jenkins/plugins/gitlab-branch-source/1.5.4-rc587.8eb7bb2eee95/, and see if that fixes the NPE.

As a possible workaround, make sure that the server has a secret token set. You might have to use the 'Advanced' button to see it? I don't have an installation of the plugin in front of me, so I don't know exactly where that is set. (I thought it was per-job, but on reflection, it must be system-wide because the plugin supports system-wide Webhooks in GitLab).

I guess the failing call is server.getSecretToken().getPlainText(), which was changed in #105 to server.getSecretTokenAsPlainText() so it can't dereference a null anymore. If I'm right, then the failure is because the GitLab server config in Jenkins doesn't have a secret token set, and the error handling for that was faulty in 1.5.3.

[Stikus]

I'll post in this issue because I don't fully understand the reason of my problem, but here it is:

1. I've added another secret token for user jenkins1 (my jenkins user for gitlab)
   
2. After that I've added this token to plugin config:
   
3. After resaving my jobs secret token was added to my webhooks and all work, but now when my job is failed gitlab sends email not to me (commiter) but to my jenkins user (jenkins1) - I assume due to secret token in webhook - looks like it detects it as jenkins1.

Is it my mistake (wrong secret token) or something wrong with settings of plugin? Before 1.5.3 and without secret token all worked fine.

[TBBle]

The "Secret Token" box in the config should not be a Personal Access Token for a GitLab user. It should be a nice long random string, because it's the token GitLab sends to Jenkins to identify its webhooks as authorised.

There's supposed to be a "Generate Secret Token" button to generate that random string, but it's not fully implemented, see #108.

I can't see how that's related to who GitLab sends emails to, since GitLab doesn't parse or use that token, it just sends it to Jenkins. You should see that token in the GitLab webhook configuration, which is why it should not be a Personal Access Token, because that's now visible in plain-text to anyone who can access the webhook config. And since you have 'Manage System webhooks' turned on, I assume jenkins1 is an Administrator account on your GitLab. -_- You probably should regenerate that PAT.

I haven't used emails with the GitLab hooks, but I would guess it's somehow using the user defined in the Credentials box here, as the one who created the webhooks? That is the token Jenkins sends to GitLab (along with the username) when it is creating webhooks and scanning projects for changes, unless an individual job specifies a different user.

Using that user seems like a bug in GitLab, but perhaps the plugin is somehow telling GitLab to send email to the user that scanned the repo, rather than the committer of the failing change. Either way, the email issue sounds like a different problem from this issue, but may have been introduced at the same time.

[Stikus]

Thanks for answer - I've generated Secret token as you suggested in #108 and updated it.
But today I've detected several other problems in jenkins logs:

Feb 10, 2021 2:52:21 PM INFO org.gitlab4j.api.webhook.WebHookManager handleRequest
handleEvent: X-Gitlab-Event=Push Hook
Feb 10, 2021 2:52:21 PM WARNING hudson.init.impl.InstallUncaughtExceptionHandler handleException
Caught unhandled exception with ID 2e1612c3-69d8-4ae3-ae42-c06dc7a8d3f8
java.lang.Exception: Expecting a valid secret token
	at org.kohsuke.stapler.HttpResponses.error(HttpResponses.java:91)
	at io.jenkins.plugins.gitlabbranchsource.GitLabSystemHookAction.doPost(GitLabSystemHookAction.java:75)
	at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:627)
	at org.kohsuke.stapler.Function$MethodFunction.invoke(Function.java:396)
	at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:408)
	at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:212)
	at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:145)
...

On webhook page all is ok - it says 200 and its working, but these errors - I don't understand their reasons.

Moreover - our old problem https://issues.jenkins.io/browse/JENKINS-55220 came back - I've lost 2 master branches on Jenkins - for some reason it thinks that master doesn't have Jenkinsfile and deleting it.

Scan log was:

Started
[Wed Feb 10 13:37:44 MSK 2021] Starting branch indexing...

Unable to detect if it is a mirror or not still fetching MRs anyway...

Checking branches.. 

Checking branch master

Checking branch release-v0.1
      ‘Jenkinsfile’ found
Met criteria
No changes detected: release-v0.1 (still at f2729094bbf1f3e1c5350c4dd5686f133ebede98)

Checking branch release-v0.2
      ‘Jenkinsfile’ found
Met criteria
No changes detected: release-v0.2 (still at 8b093df331b29e3e7fd0ab29e1703d6a3da90333)

3 branches were processed

Checking merge requests..

0 merge requests were processed
[Wed Feb 10 13:37:47 MSK 2021] Finished branch indexing. Indexing took 2.3 sec
Evaluating orphaned items in ubuntu_bisa
Will remove MR-14
Finished: SUCCESS

After I changed secret token scan triggered and found master but build history was lost (we lost another master last evening). We haven't this problem for very log time and it came back after my yesterday update.

And I have a lot of:

Feb 10, 2021 2:35:37 PM WARNING hudson.security.csrf.CrumbFilter doFilter
No valid crumb was included in request for /view/BISA%20Soft/ajaxBuildQueue by grammatikati. Returning 403.
Feb 10, 2021 2:35:37 PM WARNING hudson.security.csrf.CrumbFilter doFilter
Found invalid crumb a90e4c471297a3ecf8a4dce82e04e6ae2f5868be668209386acf02f73717088f. If you are calling this URL with a script, please use the API Token instead. More information: https://jenkins.io/redirect/crumb-cannot-be-used-for-script

But I assume its different problem.