gitlab-branch-source-plugin: No longer works without secret token

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)

About this issue

  • Original URL
  • State: open
  • Created 3 years ago
  • Reactions: 11
  • Comments: 23 (1 by maintainers)

Commits related to this issue

Most upvoted comments

@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.

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.

Adding my confirmation that after updating from 1.5.1 to 1.5.4, any new creation of a gitlab project, manual or via jobdsl, causes a NPE if the secret security token is not defined. Gitlab version: 13

Rolling back to 1.5.1 fixes the issue.

I vote that the webhook token PR be rolled back – it is not ready for GA. Lost a few hours to this today…

It should be backward compatible. If I do not have a Security Token set then it should still work. Instead saving a job threw and NPE and, meanwhile, the webhook received http 401s.

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) image
  2. After that I’ve added this token to plugin config: image
  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.

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

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

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