No longer works without secret token #106

Open kuhnroyal opened 3 years ago

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)

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.

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.

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

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

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

It seems this was a known, deliberate change per https://github.com/jenkinsci/gitlab-branch-source-plugin/pull/91#issuecomment-633235942. 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.

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

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.

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?

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.

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

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

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

I've added another secret token for user jenkins1 (my jenkins user for gitlab)
After that I've added this token to plugin config:
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.

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.

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.

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.

I'm totally confused - according to this issue: https://gitlab.com/gitlab-org/gitlab/-/issues/20281 this behavior always was the same. But 3 days ago I've received that damn emails myself and not my jenkins1 user (with nonexistent email btw - our mail support sending me errors from mail server now). I've downgraded back to 1.5.1 plugin, but this doesn't help. My only idea is that after populating secret token field it was stored somewhere, and I cannot remove it (I've cleaned webhook page and plugin page).

Update Email problem was fake - today I've discovered that our mail support only yesterday found these errors, but they were for a long time - if only jenkins is in gitlab pipeline (so only external and not own gitlab CI) it counts as trigger and received mail. If I have internal part (I have it for master branch only) - me counts as trigger and receive email.

So the only problem is java.lang.Exception: Expecting a valid secret token

For the error with invalid secret token, I expect that after changing the secret token in the config, you need to go through every Jenkins job using this plugin and resave it, so it recreates the webhooks each each GitLab project. So my guess is that a different project on your GitLab server hasn't been updated, and is sending the old token.

Sadly, the error tells us it was X-Gitlab-Event=Push Hook but not which branch of which project was pushed to.

I've no idea about the scan log and lost branches, that seems unrelated to this issue; I've not seen it on my own setup, but we're not hammering it very hard anyway, so we aren't likely to be hit by intermittent problems.

The secret token is not related to the scan, the scan uses the GitLab credentials specified here or overridden in the job. Based on that Jenkins ticket, it's more that something is weird in the general Git or SCM behaviour where it sometimes fails to find a branch.

And looking at the relevant plugin code, it appears to be up the the multibranch code, not this plugin how that works. It's interesting that master branch logged neither "Met criteria" or "Does not meet criteria", which suggests that mutli-branch plugin API just ignored the branch itself.

If this is happening a lot, perhaps setting the retention period to a few days, so that it doesn't delete the job, just disables it, and once the branch reappears, it will re-enable it. But either way, looks like a bug in the multi-branch API plugin, not in this plugin.

Yes, my thoughts were the same - I've double-checked my jobs, but all was ok. After that I've pushed commit to test webhook for real (not with test button) and error happens:
Test button:

Feb 10, 2021 5:33:13 PM INFO org.gitlab4j.api.webhook.WebHookManager handleRequest
handleEvent: X-Gitlab-Event=Push Hook

Real push:

Feb 10, 2021 5:33:50 PM INFO org.gitlab4j.api.webhook.WebHookManager handleRequest
handleEvent: X-Gitlab-Event=Push Hook
Feb 10, 2021 5:33:50 PM WARNING hudson.init.impl.InstallUncaughtExceptionHandler handleException
Caught unhandled exception with ID 2accbe05-1266-4dbe-9f23-00336e29d717
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)
    at org.kohsuke.stapler.MetaClass$11.doDispatch(MetaClass.java:536)
    at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:58)
    at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:766)
    at org.kohsuke.stapler.Stapler.invoke(Stapler.java:898)
    at org.kohsuke.stapler.MetaClass$9.dispatch(MetaClass.java:457)
    at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:766)
    at org.kohsuke.stapler.Stapler.invoke(Stapler.java:898)
    at org.kohsuke.stapler.Stapler.invoke(Stapler.java:694)
    at org.kohsuke.stapler.Stapler.service(Stapler.java:240)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
    at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:763)
    at org.eclipse.jetty.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1633)
    at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:154)
    at jenkins.telemetry.impl.UserLanguages$AcceptLanguageFilter.doFilter(UserLanguages.java:129)
    at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:151)
    at jenkins.security.ResourceDomainFilter.doFilter(ResourceDomainFilter.java:76)
    at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:151)
    at hudson.plugins.locale.LocaleFilter.doFilter(LocaleFilter.java:42)
    at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:151)
    at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:157)
    at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
    at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1609)
    at io.jenkins.plugins.gitlabbranchsource.GitLabSystemHookAction.process(GitLabSystemHookAction.java:49)
    at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:127)
    at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
    at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1609)
    at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
    at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51)
    at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
    at jenkins.security.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:119)
    at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
    at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
    at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
    at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:135)
    at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
    at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271)
    at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
    at jenkins.security.BasicHeaderProcessor.doFilter(BasicHeaderProcessor.java:93)
    at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
    at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
    at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67)
    at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
    at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:90)
    at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:171)
    at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
    at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1609)
    at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:51)
    at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
    at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1609)
    at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:82)
    at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
    at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1609)
    at org.kohsuke.stapler.DiagnosticThreadNameFilter.doFilter(DiagnosticThreadNameFilter.java:30)
    at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
    at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1609)
    at jenkins.security.SuspiciousRequestFilter.doFilter(SuspiciousRequestFilter.java:36)
    at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
    at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1609)
    at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:561)
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
    at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:578)
    at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
    at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
    at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1612)
    at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
    at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1434)
    at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
    at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:501)
    at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1582)
    at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
    at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1349)
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
    at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
    at org.eclipse.jetty.server.Server.handle(Server.java:516)
    at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
    at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:556)
    at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
    at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
    at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
    at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
    at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
    at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:375)
    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:773)
    at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:905)
    at java.lang.Thread.run(Thread.java:748)

Feb 10, 2021 5:33:51 PM INFO io.jenkins.plugins.gitlabbranchsource.helpers.GitLabPipelineStatusNotifier$JobScheduledListener lambda$onEnterWaiting$0
Querying the current revision of branch hotfix_args...
Feb 10, 2021 5:33:51 PM INFO io.jenkins.plugins.gitlabbranchsource.helpers.GitLabPipelineStatusNotifier$JobScheduledListener lambda$onEnterWaiting$0
Current revision of branch hotfix_args is edb8091fbfeb4b5cdfb8837fd157bad290cdf8d3
Feb 10, 2021 5:33:51 PM INFO io.jenkins.plugins.gitlabbranchsource.helpers.GitLabPipelineStatusNotifier$JobScheduledListener lambda$onEnterWaiting$0
Notifying branch pending build python-cwltool/hotfix_args
Feb 10, 2021 5:33:51 PM INFO io.jenkins.plugins.gitlabbranchsource.helpers.GitLabPipelineStatusNotifier$JobScheduledListener lambda$onEnterWaiting$0
python-cwltool/hotfix_args Notified
Feb 10, 2021 5:34:11 PM INFO org.jenkinsci.plugins.workflow.job.WorkflowRun finish
python-cwltool/hotfix_args #8 completed: SUCCESS

If this is happening a lot, perhaps setting the retention period to a few days, so that it doesn't delete the job, just disables it, and once the branch reappears, it will re-enable it. But either way, looks like a bug in the multi-branch API plugin, not in this plugin.

We used this option for some time, but the problem disappears, and I've enabled deleting back. I'll look into it, thanks for answers about this part too.

I've just noticed, the log is coming from GitLabSystemHookAction.java, not GitLabWebHookAction.java.

So it's the hook added to the GitLab system webhooks for detecting job deletion, not the hook attached to the individual GitLab repository.

I think this is a bug in the changes for the webhook token, as Webhooks have their token updated on save, but System hooks lack that code.

I think you should log that as a new issue, that changing the secret token in the Jenkins configuration does not update the system hook in GitLab if it already exists.

In the meantime, I'd suggested either fixing the system hook in GitLab to have the right token, or deleting it, and resaving the GitLab config in Jenkins, which should trigger it to recreate the system hook.

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.

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.

After setting up the token correctly things seem to be working fine. I think there are two lessons here:

release management: take semver seriously and mark breaking changes requiring manual intervention by not just bumping the patch level.
error handling: Letting NPEs bubble up is not very graceful failing. Perhaps improve error reporting and logging of plugin errors.

Would the code change mentioned in comment by @skundrik here https://github.com/jenkinsci/gitlab-branch-source-plugin/pull/105#discussion_r553940971 fix NullPointerException upon rescanning group folder jobs after upgrade (to attempt to fill empty webhook secret tokens)?

jenkinsci / gitlab-branch-source-plugin

No longer works without secret token #106