Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-63186

Allow setting ID for personal access token

    XMLWordPrintable

Details

    Description

      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.

      Attachments

        Issue Links

          Activity

            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.

            kon 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.

            gpaciga 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.

            kon 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 .

            People

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

              Dates

                Created:
                Updated: