Gitlab-plugin: Secret token disappeared after first success build?

[Daggerphobia]

Issue

Context

• Gitlab plugin version: 1.5.11
• Gitlab version: 11.9.11
• Jenkins version: 2.150.3
• Job type: Pipeline, Freestyle, Matrix, etc.

Logs & Traces

N/A

Problem description

I integrated jenkins trigger with gitlab webhook. I can be triggered 200 successfully with secret token. But after the first hook, secret token disappeared on Jenkins side. When gitlab try to post another one, it could not reach because the same token not exists on Jenkins side. Is this bug or am I missing something ?
I can success with disable authentication for '/project' end-point.But for security I don't want to disable it.

[bertbuchholz]

I have the exact same issue, job is set up as a "Declarative Pipeline".

• Gitlab plugin version: 1.5.12
• Gitlab version: 12.0.2
• Jenkins version: 2.176.1
• Job type: Declarative Pipeline

If any further information is required, please let me know.

As an update, because I just noticed the downgrade option in Jenkins Plugin Manager: It seems to work with plugin version 1.5.10. I'll test some more to be sure.

Update 2: With 1.5.10, it worked a couple of times (i.e., several push events worked) but at some point, it also failed as before and checking Jenkins then, the secret token was gone from the config.

[tkluza]

Same problem here. Any solution yet?

[stanislaw]

I am having this issue with 1.5.13.

Can confirm this with 1.5.13:

Update 2: With 1.5.10, it worked a couple of times (i.e., several push events worked) but at some point, it also failed as before and checking Jenkins then, the secret token was gone from the config.

@tkluza @bertbuchholz have you found any solution to this since then?

It is becoming a reason for us to move away from Jenkins altogether to solutions like GitLab CI or Buildbot.

[markyjackson-taulia]

I will take a look at this

[bertbuchholz]

@tkluza @bertbuchholz have you found any solution to this since then?

No, but I haven't tried it yet with 1.5.13 which would have been in vain anyway, it seems. ;)

I also stopped using Jenkins entirely due to this, because clearly it makes it completely unusable. We are already using Gitlab but I found Jenkins to be easier to set up for multi-repo projects which is why it's such a pity that this bug makes it impossible to use.

[stanislaw]

I have asked for some time in this sprint to give this a last chance: I will enable the GitLab Plugin's logs, re-create a token and start merging some of our pending MRs. When this happens again, I hope to find at least something in the logs that would explain why this happens.

Any advices from you guys on how to investigate this are appreciated.

[edlevin6612]

Seeing similar behavior:

In my case, this issue manifests itself upon Jenkins restart. The Secret token field is cleared in job UI and webhooks from Gitlab start returning 403s.

However, if I look at the same job's config.xml on the file system I see the encrypted secret populated within <secretToken> and I can even decode it by running the following in the script console:

println(hudson.util.Secret.decrypt("{my-encoded-secret-here=}"))

And, if I force a reload of the job via the script console the secret token on the job is populated again and the webhook starts working:

```import java.io.InputStream;
import java.io.FileInputStream
import java.io.File;
import javax.xml.transform.stream.StreamSource

def job = Jenkins.instance.getItemByFullName("my-job-name")
def configXMLFile = job.getConfigFile();
def file = configXMLFile.getFile();
InputStream is = new FileInputStream(file);

job.updateByXml(new StreamSource(is));
job.save();
```

So somehow the configured secret value is not registering with the job upon restart.

Thank you.

Jenkins: 2.222.3
Gitlab plugin: 1.5.13

[edlevin6612]

Nevermind, overlooked a Jenkins startup script that was explicitly resetting the security tokens 🤦

[dennisjansen]

I have same Problem with
Jenkins 2.249.1 LTS
Gitlab plugin 1.5.13

is this the same Problem, how can it be fixed?

[lvincel]

Same problem here with latest LTS 2.249.1 and 1.5.13
A definite show stopper for this plugin

[lvincel]

I found a solution for my case. It turned out it was the trigger section in my Jenkinsfile that overrode the configuration; which makes sense actually, it overrides the full thing hence erasing the token.
I removed the trigger section, reconfigure UI-wise the trigger in Jenkins and now it's stable and token is not erased.