This is related to https://github.com/jenkinsci/bitbucket-branch-source-plugin/issues/706

It seems as "Secret text" credentials are not included in the creds list for Bitbucket Cloud instances. But even if in my case I'm selecting a Bitbucket Server instance, the initial configuration page seems to handle it as a cloud instance and thus not showing the "Secret text" credential. But when editing an existing multibranch-pipeline it seems to handle it correctly as a Server instance and therefore shows the "Secret text" credential.

After further investigation I'm not sure this is exactly related to https://github.com/jenkinsci/bitbucket-branch-source-plugin/issues/706. Rather it's more related to https://github.com/jenkinsci/bitbucket-branch-source-plugin/issues/416.

What I see is that when selecting a "Bitbucket" branch source when creating a multibranch pipeline project, the Server lsit is populated and the first element is pre-selected. However, the serverUrl is not fecthed so the following request for validating server is done for the "" server url. The smae problem for the request to populate the credentials listbox. An empty ("")) serverUrl is provided in the requests.
But if a different server is selected then the serverUrl is retrieved and used and the credentials listbox is correctly populated.

As a workaround we've added a dummy server element "Select server" which forces the end user to select a different server and then this issue is worked around. Not ideal, but works for now.

I did some debugging of the JS frontend on a fresh Jenkins v2.426 with the Bitbucket Branch Source plugin 848.v42c6a_317eda_e. In the global settings I have the Bitbucket Cloud Endpoint.

If I understand correctly, here is the expected sequence when adding a branch source to a Job:

1. The serverUrl select is filled by a POST request to fillServerUrlItems
2. When the selected value of the serverUrl select changes, all observers are notified; this includes the credentialsId select.
3. The credentialsId select is updated by a POST request to fillCredentialsIdItems with the parameter serverId set to the newly selected value of the serverUrl select. This is where things go wrong because on the first request to fillCredentialsIdItems, the serverId parameter is empty. A second request with the updated server URL never happens.

The serverUrl select is filled on line 135 in jenkins/core/src/main/resources/lib/form/select/select.js at master · jenkinsci/jenkins (github.com) by calling updateListBox:

updateListBox(e, e.getAttribute("fillUrl"), {
  parameters: params,
  onSuccess: function () {
    if (value == "") {
      // reflect the initial value. if the control depends on several other SELECT.select,
      // it may take several updates before we get the right items, which is why all these precautions.
      var v = e.getAttribute("value");
      if (v) {
        e.value = v;
        // we were able to apply our initial value
        if (e.value == v) {
          e.removeAttribute("value");
        }
      }
    }
 
    fireEvent(e, "filled"); // let other interested parties know that the items have changed

    // if the update changed the current selection, others listening to this control needs to be notified.
    if (hasChanged(e, value)) {
      fireEvent(e, "change");
    }
  },
});

This leads to a POST request to fillServerUrlItems which returns the value "https://bitbucket.org" as expected.

In the onSuccess callback we conditionally fire the "change" event which would in turn trigger a refill of the credentialsId select. The problem is that hasChanged returns false for an initial fill so the credentialsId select is never updated with the new server URL.

Unfortunately I'm not sure how to fix this. There is likely a good reason for not considering the initial fill of a select as a "change" so I would not touch the implementation of hasChanged. Maybe the credentialsId select should observe the "fill" event in addition to the "change" event although I don't know how one would implement this.

It seems like the dependency of the credentialsId select to the serverUrl select is declared in the HTML select tag:

<select checkdependson="serverUrl" fillurl="/job/test/descriptorByName/com.cloudbees.jenkins.plugins.bitbucket.BitbucketSCMSource/fillCredentialsIdItems" checkurl="/job/test/descriptorByName/com.cloudbees.jenkins.plugins.bitbucket.BitbucketSCMSource/checkCredentialsId" filldependson="serverUrl" name="_.credentialsId" class="jenkins-select__input validated select credentials-select" value=""><option value="">- none -</option></select>

Note the filldependson="serverUrl".

Hopefully someone with more front-end experience than me (> 0) can figure this out :^)

As documented available credential are:

• Access Token (Username / password credential type)
• App Passwords (Username / password credential type)
• OAuth credentials (Username / password credential type)
• SSH configured as trait

nfalco Please read the full description of this ticket. "Secret text" credentials are listed if I edit an existing pipeline, but not when creating a new one. So it's inconsistent and there is a bug. I also argue that the documentation is wrong as "secret text" is the only reasonable credentials type for an HTTP access token as they can be created on Bitbucket project or git repo where they are not linked to a user account. Hence there is no username to provide if using "username and password" credentials.

Maybe the pipeline was before the changes to the authentication and when Jenkins load the old configuration by default the UI propose the actual value (this the case also when you do not have permission).
HTTP access token is a username/password because as per atlassian documentation you must have a username and than create an HTTP token.
https://confluence.atlassian.com/bitbucketserver080/http-access-tokens-1115142284.html
For project or repository tokens, you must only use Bearer Auth without the username, Bitbucket plugin handle all those authentication at runtime registering to the git plugin a new StandardUsernamePassowrdCredentialImpl as user an empty string and as password the HTTP token or the generated OAuth2 token.
I will not change to the actual mechanism to introduce support to other types of authentication, please update old credential to the requested type as described in the plugin documentation for HTTP access token with the username account used for HTTP or any username.
This is the reason I'm closing this issue.

I'm very sorry, I misunderstood this issue. I wasn't clear to me what the problem was in the description. I thought it was a request to support additional credential Jenkins types.

It's clear now that is the same issue of JENKINS-75073 caused by wrong selection of credentials based on server URL.

The issue now should be fixed as for JENKINS-75073. I'm changing the resolution