When creating a personal access token credential, there is no way to set the credential ID, unlike most other credential types.

      The advantage to being able to do this is that the credential ID can be used in pipelines and JobDSL code in a consistent way across multiple servers. I want to be able to assume in a Job DSL specification that a personal access token must exist with a given ID. As it's currently set up, I have to add the credential to Jenkins to get its randomly assigned ID, and then commit that to my various pipeline scripts.

      I know there are workarounds - e.g. putting the credential ID into an environment variable - but this is out of step with other credential types.

          [JENKINS-63186] Allow setting ID for personal access token

          Are you actually able to access the credential in pipeline scripts if you know its ID? In JENKINS-61277, I reasoned that the credential is always in SYSTEM scope (rather than in GLOBAL scope) and therefore cannot be accessed by withCredentials. I don't know whether Job DSL has the same restriction.

          Kalle Niemitalo added a comment - Are you actually able to access the credential in pipeline scripts if you know its ID? In JENKINS-61277 , I reasoned that the credential is always in SYSTEM scope (rather than in GLOBAL scope) and therefore cannot be accessed by withCredentials . I don't know whether Job DSL has the same restriction.

          Job DSL is a different specification, not a pipeline script; it does not use `withCredentials`. You essentially write in code what you would enter in the job configuration UI screen. So, where this plugin asks for credentials for build auth:

          Job DSL would be configured like so:

          multibranchPipelineJob("Job_Name") {
               branchSources {
                  branchSource {
                      source {
                          BbS {
                              credentialsId 'id-for-personal-access-token'
                              projectName 'myproject'
                              repositoryName 'myrepo'
                              //etc
                          }
                      }
                  }
              }
          }
          

          The BbS block and the options available in it is automatically generated by Job DSL because (I presume) there's not official support for Job DSL in this plugin yet.

          This is where I'd want a stable `credentialsId` that I can commit, as can be done with other credentials.

          Gregory Paciga added a comment - Job DSL is a different specification, not a pipeline script; it does not use `withCredentials`. You essentially write in code what you would enter in the job configuration UI screen. So, where this plugin asks for credentials for build auth: Job DSL would be configured like so: multibranchPipelineJob( "Job_Name" ) { branchSources { branchSource { source { BbS { credentialsId 'id- for -personal-access-token' projectName 'myproject' repositoryName 'myrepo' //etc } } } } } The BbS block and the options available in it is automatically generated by Job DSL because (I presume) there's not official support for Job DSL in this plugin yet. This is where I'd want a stable `credentialsId` that I can commit, as can be done with other credentials.

          This was implemented in PR #218 and released in atlassian-bitbucket-server-integration version 2.1.2 in January 2021.

          However, the implementation seems to be a bit incorrect: when I edit a previously saved Bitbucket admin token credential, it shows a message saying that the credential ID is already in use. I think that happens because config.groovy itself creates fields for the ID and description, instead of using id-and-description.jelly as recommended in BaseStandardCredentialsDescriptor.

          Kalle Niemitalo added a comment - This was implemented in PR #218 and released in atlassian-bitbucket-server-integration version 2.1.2 in January 2021. However, the implementation seems to be a bit incorrect: when I edit a previously saved Bitbucket admin token credential, it shows a message saying that the credential ID is already in use. I think that happens because config.groovy itself creates fields for the ID and description, instead of using id-and-description.jelly as recommended in BaseStandardCredentialsDescriptor .

            Unassigned Unassigned
            gpaciga Gregory Paciga
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: