Search code examples
jenkinsjenkins-plugins

Jenkins API Credential difference between PersonalAccessTokenImpland GitlabAPiTokenImpl

I have inherited management of some legacy Jenkins infrastructure and I am confused because I have two types of Gitlab API Tokens in my credentials:

 {
    "apiToken": "**********",
    "description": "GitLab API token (Gitlab token for ops user)",
    "id": "cicd-gitlab",
    "scope": "GLOBAL",
    "class": "com.dabsquared.gitlabjenkins.connection.GitLabApiTokenImpl"
  },
  {
    "description": "A-gitlab-token (cicd-gitlab-token)",
    "id": "cicd-gitlab-token",
    "scope": "GLOBAL",
    "class": "io.jenkins.plugins.gitlabserverconfig.credentials.PersonalAccessTokenImpl",
    "token": "****-*****_*****"
  },

Can anyone shed some light about what is the difference between the API token and the token, as they have two different classes?

Solution

  • Put simply, they're two different credential types from two different plugins:

    Both credential types store the exact same sorts of secrets: GitLab Access Tokens. So why are there two different implementations for the same kind of secrets? It's an historical quirk rather than a deliberate design decision or a technical necessity. The GitLab Plugin came first, but was judged to have some major flaws and did not support Multibranch Pipelines or Organization Folders, spawning the creation of the GitLab Branch Source Plugin. Yes, there is quiet a bit of overlap between the two plugins. Yes, they could be refactored to share a common credential implementation, but they currently do not. The GitLab Branch Source Plugin has its own shortcomings with respect to credential scope, too, making it a poor choice for multi-tenant Jenkins controllers.

    On the global Jenkins system configuration page (/manage/configure), you'll see that the Credentials dropdown in the GitLab Plugin section allows you to choose a "GitLab API token" credential, while the Credentials dropdown in the GitLab Branch Source Plugin section allows you to choose a "GitLab Personal Access Token", but neither allows you to select a credential type from the opposing plugin.

    Recent versions of both GitLab plugins now allow you to use the more generic org.jenkinsci.plugins.plaincredentials.impl.StringCredentialsImpl ("Secret text") credential type for their global configuration, which might have some benefits. Storing your GitLab access tokens in as generic "Secret Text" credentials rather than the plugin-specific credential types ensures you won't need to duplicate your GitLab token in two different Jenkins credentials when utilizing features from both plugins.

    And, if your pipelines have a need to read the same GitLab token that's used for global plugin configurations, using "Secret text" credentials also permits you to use the standard withCredentials([string(credentialsId: 'gitlab-token-cred', variable: 'GITLAB_TOKEN')]) { ... } syntax in a pipeline, which isn't possible with the plugin-specific types.

    (Prior to June, 2023, the GitLab Branch Source Plugin required you to utilize the plugin-specific "GitLab Personal Access Token" (PersonalAccessTokenImpl) credential, but that behavior was modified in https://github.com/jenkinsci/gitlab-branch-source-plugin/pull/326, making the shared "Secret text" credential thing described above possible.)

    If you look at the GitHub "Issues" for both plugins, you can see that there is lots of ongoing confusion about these GitLab credential types among Jenkins users. It's definitely an area that could use some attention from willing developers.