Gitlab-plugin: withCredentials in pipeline not supported

[ehaselwanter]

Issue

withCredentials in pipelines is not supported with custom secrets type

node {
   withCredentials([string(credentialsId: 'gitlab_jenkins_api_token_connection', variable: 'TOKEN')]) {
                sh('''#!/bin/bash -xe
                  echo hello
                  ''')
   }
}

Context

• Gitlab plugin version: 1.4.5
• Jenkins version: 2.46.1
• Job type: Pipeline

Logs & Traces

Running on master in /var/lib/jenkins/jobs/credentials-test/workspace
[Pipeline] {
[Pipeline] withCredentials
[Pipeline] // withCredentials
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
org.jenkinsci.plugins.credentialsbinding.impl.CredentialNotFoundException: Credentials 'gitlab_jenkins_api_token_connection' is of type 'GitLab API token' where 'org.jenkinsci.plugins.plaincredentials.StringCredentials' was expected
    at org.jenkinsci.plugins.credentialsbinding.MultiBinding.getCredentials(MultiBinding.java:164)
    at org.jenkinsci.plugins.credentialsbinding.impl.StringBinding.bindSingle(StringBinding.java:62)
    at org.jenkinsci.plugins.credentialsbinding.Binding.bind(Binding.java:150)
    at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Execution.start(BindingStep.java:114)
    at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:184)
    at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:126)
    at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:108)
    at groovy.lang.GroovyObject$invokeMethod.call(Unknown Source)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
    at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:151)
    at org.kohsuke.groovy.sandbox.GroovyInterceptor.onMethodCall(GroovyInterceptor.java:21)
    at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:115)
    at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:149)
    at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:146)
    at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:123)
    at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:16)
    at WorkflowScript.run(WorkflowScript:2)
    at ___cps.transform___(Native Method)
    at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:57)
    at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)
    at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
    at com.cloudbees.groovy.cps.impl.ClosureBlock.eval(ClosureBlock.java:46)
    at com.cloudbees.groovy.cps.Next.step(Next.java:74)
    at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:154)
    at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18)
    at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:33)
    at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:30)
    at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:108)
    at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:30)
    at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:165)
    at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:328)
    at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(CpsThreadGroup.java:80)
    at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:240)
    at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:228)
    at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:64)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112)
    at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
Finished: FAILURE

Problem description

I tried to do re-use the Token for some custom API steps. Which actually works. Just not with the custom credentials type.

current workaround is to add the token twice. as a string credential as well as a gitlab token credential.
why is it a special type anyway?

[nisaea]

Hi, think I have the same issue, but I'm not sure how to access the error logs to make sure of it (I can't even ssh on the machine running Jenkins). In my case, the tokens that are available in the "Configure System" page don't show up in the Pipeline configuration page. Only a username/password credential that is unrelated shows up. Could you please help me determine if this is the same issue? Thanks!

What I'm working with:

• GitLab plugin v1.4.5
• Jenkins v2.53

[omehegan]

Dupe of #494 I think.

[dcuenot]

Hi, @omehegan I don't understand your answer.

494 is related to Secret token, and this issue is related to Api_Token.

If I'm not wrong, those are 2 differents token, right?

[omehegan]

@dcuenot this is an old bug, so I don't remember the context anymore. Re-reading it, it appears that the OP was saying that Pipeline's withCredentials does not support the GitLab credential types that this plugin defines. That would apply to both the API token and the secret token. But if this is an issue, it's in the Jenkins Credentials plugin, not this plugin. #494 is asking us to support the built-in credentials types, so that withCredentials will work. At least that's what I think.

[anapsix]

I believe the proper usage is as follows

environment {
  GITLAB_API_TOKEN = credentials('gitlab_api_token')
}

## or

withCredentials([[
  $class: 'com.dabsquared.gitlabjenkins.connection.GitLabApiTokenImpl',
  credentialsId: 'gitlab_api_token',
  variable: 'GITLAB_API_TOKEN'
]])

The original issue author's mistake was using string as credential type, while it should be com.dabsquared.gitlabjenkins.connection.GitLabApiTokenImpl

However, even using it properly produces an error:

org.jenkinsci.plugins.credentialsbinding.impl.CredentialNotFoundException: No suitable binding handler could be found for type com.dabsquared.gitlabjenkins.connection.GitLabApiTokenImpl. Supported types are StandardUsernamePasswordCredentials,FileCredentials,StringCredentials.
    at org.jenkinsci.plugins.pipeline.modeldefinition.model.CredentialsBindingHandler.forId(CredentialsBindingHandler.java:112)
[... snip ...]

[krishnafims]

I believe the proper usage is as follows

environment {
  GITLAB_API_TOKEN = credentials('gitlab_api_token')
}

## or

withCredentials([[
  $class: 'com.dabsquared.gitlabjenkins.connection.GitLabApiTokenImpl',
  credentialsId: 'gitlab_api_token',
  variable: 'GITLAB_API_TOKEN'
]])

The original issue author's mistake was using string as credential type, while it should be com.dabsquared.gitlabjenkins.connection.GitLabApiTokenImpl

However, even using it properly produces an error:

org.jenkinsci.plugins.credentialsbinding.impl.CredentialNotFoundException: No suitable binding handler could be found for type com.dabsquared.gitlabjenkins.connection.GitLabApiTokenImpl. Supported types are StandardUsernamePasswordCredentials,FileCredentials,StringCredentials.
  at org.jenkinsci.plugins.pipeline.modeldefinition.model.CredentialsBindingHandler.forId(CredentialsBindingHandler.java:112)
[... snip ...]

where we need to add this environment test in Gitlab CI.

[lukaszkubisiak-intel]

Hi,
Why this issue is closed? Do we have a solution for this?
The workaround is to save the same api key as standard string (Secret text), but I will have two entries for one api key.

[arvera]

I tried the secret text approach but I still got a similar error:

is of type 'Secret text' where 'com.cloudbees.plugins.credentials.common.StandardUsernamePasswordCredentials' was expected

[arvera]

Not sure why this is closed, https://github.com/jenkinsci/gitlab-plugin/issues/536#issuecomment-313304024 is not the same.