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]

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.

[it-mak]

any news?

[krisstern]

Hi @it-mak Could you please provide us with more details on the context of your issue so we could look into it?

[thaarbach]

Is there any new on this issue? I tried https://github.com/jenkinsci/gitlab-plugin/issues/536#issuecomment-433079654 what is not working.

withCredentials([string(credentialsId: 'gitlab_jenkins_api_token_connection', variable: 'TOKEN')]) 

[ytianxia6]

I also get this error :

ERROR: Credentials 'gitlab-token' is of type 'GitLab API token' where 'org.jenkinsci.plugins.plaincredentials.StringCredentials' was expected

and is there any solution now?

my pipeline is

    withCredentials([string(credentialsId: 'gitlab-token', variable: 'API_KEY')]) {
         sh "echo API Key is ${API_KEY}"
    }

[rcfja]

I also got this error. Of course the "solution" was switch to secret text. But I wish this would get implemented instead.

[daddyy]

Still there is no solution instead use the secret text?

[damnmso]

yep, still no solution, just hit the same problem. so i will go with secret text for the api token

[Olisa-K]

Still the same error with declarative form

    environment{
        GITLAB_TOKEN = credentials("serviceToken")
    }

produces

ERROR: No suitable binding handler could be found for type com.dabsquared.gitlabjenkins.connection.GitLabApiTokenImpl. Supported types are StandardUsernamePasswordCredentials,FileCredentials,DockerServerCredentials,StringCredentials,SSHUserPrivateKey.

Jenkins 2.426.3 GitLab Plugin 1.8.1

[benipeled]

Same here - an attempt to use GitLab Personal Access Token fail with

ERROR: No suitable binding handler could be found for type io.jenkins.plugins.gitlabserverconfig.credentials.PersonalAccessTokenImpl

The workaround is using Secret text

[drakgoku]

Well, I think the solution will be to put it in a secret text in Jentkins. The problem? We will lose access to the API.

So, is it a solution? No. It's a pirate patch.

If we have a variable to check, get other things like URLs, messages... and it doesn't work... it's like having a car without a key.

Can someone look at it? If this was mentioned in 2018, it's been about 6 years now. I hope that by 2030 my grandson can enjoy this nonsense.

[MarkEWaite]

Well, I think the solution will be to put it in a secret text in Jenkins. The problem? We will lose access to the API.

No, you won't lose access to the API. You will need to remember that when you update the credential on the remote server, it must be updated in two locations in Jenkins instead of being updated in one location. I agree that is a burden, but you do not lose access to the API.

Can someone look at it?

Yes. You can look at it. When you have the code change working, have added automated tests to confirm the code change is working, and have added documentation showing examples that use your newly added code, I'm sure we can find a reviewer for your pull request.

If you decide that you'd rather not look at it, then you can use the already described workaround of using a secret text credential.

[drakgoku]

Let's take it one step at a time.

No, you won't lose access to the API. You will need to remember that when you update the credential on the remote server, it must be updated in two locations in Jenkins instead of being updated in one location. I agree that is a burden, but you do not lose access to the API.

The gitlab variable/token created in the credentials is supposed to have more functionality than just a secret-text / plain text with the encrypted key.

While "Secret text" offers more flexibility, using the GitLab variable provides a more specific and potentially more secure integration for working with GitLab.

The GitLab variable offers a closer integration with the GitLab API. That is, it already comes with methods, functions, functionalities, and more. It's like having a key to a house, but I have to get in using a generic key or a lockpick. This example is something close to what we do.

Yes. You can look at it.

I don't have time. I'm on a mega project. I don't know how I had time or am having time to respond. I hope you can fix it. I'll keep it simple for now, using secret text. In the future I'll use ssh, which I think will be better.